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ABSTRACT 

This thesis describes the detailed design of a 
distributed operating system for a real-time, microcomputer 
based multiprocessor system. 

Process structuring and segmented address spaces 
comprise the central concepts around which this system is 
built. The system particularly supports applications where 
processing is partitioned into a set of multiple processes. 
One such area is that of digital signal processing for which 
this system has been specifically developed. 

The operating system is hierarchically structured to 

logically distribute its functions in each process. This and 
loop-free properties of the design allow for the physical 
distribution of system code and data amongst the 
microcomputers. In a multiprocessor configuration, this 
physical distribution minimizes system bus contention and 
lays the foundation for dynamic reconfiguration. 
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I. INTRODUCTION 



A. DISCUSSION 

The topic of this thesis is the detailed design of the 
kernel of a real-time microcomputer based multiprocessor 
operating system. The kernel comprises a complete, albeit 
primitive, operating system providing support for a large 
number of asynchronous processes. 

The kernel manages all physical processor resources 
thereby providing the user with an execution environment 
relatively free from concern about the underlying hardware 
configuration. The system is capable of performing in a 
real-time environment through the use of preemptive 
scheduling to ensure expeditious handling of time-critical 
processing requirements. 

Despite the rapidly expanding capabilities of modern 
microcomputer systems, they still prove to be limited by the 
relatively slow execution speeds of their microprocessors. 
These systems generally do not provide the power and 



flexibility 


requi red 


to address 


complex and 


demanding 


applications 


. One such 


area is 


that 


of real-til 


me digital 


image processing. 


This is 


a 


parti cul arly 


demanding 


application 


area characterized 


by the 


requirement 


to apply 


significant 


pro cessing 


power to 


a high input data 


rate . 
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A natural ans'wer to the inadequacies of the lone 
microcomputer is to provide for multiple microcomputer 
systems. Such systems could provide the processing power to 
adequately handle applications which are presently addressed 
only within the domain of minicomputers and mainframe 
systems. However, the general purpose microcomputer 
operating system which would control such a system does not 
exist today. Most of today's microcomputer operating systems 
deal only with uniprocessors and, in fact, could not 
adequately manage multiple processors. 

The integration of large numbers of relatively 
inexpensive microcomputers into powerful computer systems 
has been the subject of intensive research in universities 
and industry for several years. As a result, a number of 
multiple microcom.pute r systems such as Carnegie-Mellon 's Cm’*' 
[18] have been built and even more such as the varied 
architectures of Anderson and Jensen [l] have been 
suggested. The Cm’*' is an ambitious system with 5 £ processors 
and a complex, custom designed and built bus structure [IS]. 
Most of the proposed systems require this type of 
specialized hardware. The primary thrust of this thesis is 
towards a general control structure which can be applied to 
hardware systems that are commercially available today with 
only very minor or no hardware development. Thus no serious 
attempt is made to consider alternative hardware 
architectures as a topic in this research. 
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A complete high level operating system design was 



provided hy O'Connell and Richardson 
secure multiprocessor operating 
concerns itself with the detailing; o 
family, a modified real-time su 
consists of the inclusion of a more 
mechanism, eventcounts and sequence 
Kanodia [13] which replace the more 
and Block/Wakeup used in the orisina 
The system supports multiple 
usins the concept of two-level traff 
processor multiplexing amongst a gre 
processes. This dual-level proces 
allows the system to treat the 
decisions, viz., the scheduling 
management of processors at two 
abstraction. 



[11] in their family of 
systems. This thesis 
f one member of their 
bset. The mcdification 
general synchronization 
rs described by Reed and 
traditional Signal/Wait 
1 design. 

asynchronous processes 
ic control to accomplish 
ater number of eligible 
sor multiplexing design 
two primary scheduling 
of processes and the 
Separate levels of 



B. STRUCTURE OF THE TRESIS 



Chapter II describes the overall design philosophy of 
the operating system, how multiple processes are 
synchronized and how their multiplexing on a smaller set of 
processors is accomplished. Chapter 3 describes the hardware 
architecture of the multiprocessor system in terms of the 
particular hardware suite chosen for this system. Chapter IV 
discusses the details of the kernel design. The final 
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chapter presents conclusions and observations that resulted 
from this effort and suggestions for further research. Two 
appendices are also provided, an explanation of programmine 
methodology for this system and a detailed description of 
the kernel modules in their present form. 
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II. rUNDAMENTAL DESIGN CONCEPTS 



A. DESIGN PHILOSOPHY 

r^ultiple processor systems are intrinsically more 
complex then the familiar uniprocessor. Their complexity has 
proven to he the major harrier to realizing the full 
potential of the inherent parallelism available in such a 
system . 

One of the most important components of any computer 
system is the operating system. The operating system manages 
the system's resources. Thus system performance is 
critically dependent upon its effectiveness. However, 
performance is not just raw computational speed, hut is in 
reality the sum-total of numerous attributes. Some of these 
system attributes such as ease of programming, correct 
operation, and the ability to address diverse applications 
are as important as speed and efficiency, but too often are 
overlooked. Because of this potentially very large set of 
requirements, adequate performance can only be assured if 
the behavior of the system is well understood by the 
designer. Of necessity, this imposes a strict requirement 
for simplicity. 

In this design, the requirement for simplicity is 
satisfied by utilizing a model based on the notion of 
multiple asynchronous processes with segmented address 
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spaces. This is the central unifying concept which provides 
a straightforward view of both static and dynarric system 
behavior [4]. The principles of structured system design are 
also applied to logically organize the operating system into 
a hierarchically structured set of easily understood modules 
whose interactions are clearly specified and strictly 
enf 0 reed . 

The result is a modular, layered operating sytem which 
is both smaller and easier to analyze. This, in turn makes 
it easier to ensure correct operation and provides better 
opportunity for improving performance through tuning. 
Certain other benefits accrue from s impl i f i ca ton as well. 
Because the sytem is smaller, less memory is used for 

operating system code and less processor time is spent in 
its execution. 

i. SEQUENTIAL PROCESSES 

1 . Definition of a Process 

The concept of a process has proven to be a 
fundamental and powerful one in the organization of computer 
systems. The rather abstract idea of a process has been 

defined in numerous ways, but perhaps the simplest is 

offered by J. Saltzer as: 

” , . .has ically a program in execution on a processor.” fl7] 
In considering the above definition, it becomes 
apparent that there are two elements which together 
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completely characterize a ^iven process. They are 1) the 
program, consisting of any sequentially executed machine 
instructions and data which can he associated with the 
program (usually termed the process' address space) and, 2) 
the execution state of the process which is characterized ly 
the contents of certain processor registers. 

2 . The Process Address Space 

The address space, simplistically, provides for the 
encapsulation of a process such that it has no knowledge of 
any other process and no other process has knowledge of it. 
This eliminates the possibility of inter-process 
interference simply because processes are unable to "escape” 
the confines of their defined address spaces. 

However, this is rather restrictive in that 
processes which are totally ignorant of each other have no 
hope of co-operating towards the accomplishment of some 
greater roal. In order to mediate this constraint, one 
desires to allow some restricted (controlled) form of 
address space overlap (viz., sharing) such that co-operation 
is allowed while still retaining the benefits of protection 
offered by isolation. Sharing requires some way cf 
distinguishing the shared portions of the address space. 
This is greatly facilitated by introducing the notion of 
memory segmentation. 
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a. Virtual ^iemory and. Sedimentation 

Virtual memory is used to implement the concept 
of a per process address space. In Multics [2], each process 
is provided with its own virtual memory for an address 
space. These virtual memories are completely independent of 
one another. 

A virtual memory consists of a set of sediments. 
Segments are distinct variable size memory objects which 
contain information. Associated with a sediment is a set of 
logical attributes used to uniquely identify the segment and 
to control access to it. 

In specifying the set of segments that comprise 
a virtual memory, one may include segments that are part of 
other virtual memories as well. Thus segments can be shared 
in a controlled manner to provide for inter-process 

communication and co-operation. 

By using segmentation to provide a virtual 
memory environment, the user is presented with a 
configuration independent system in that he "sees" a process 
address space that he can consider his own and is not 
dependent on the assignment of physical addresses. 

b. Addressing in a Segmented System 

Addressing in a segmented memory system is 
two-dimensional. That is, a complete a-ddress consists of two 
parts. The first is the segment number. This identifies the 
particular segment of interest. One attribute of the segment 
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is the physical address of the segment's "base. Thus the 
sesrment can he located anywhere in physical memory hy 
changing the base address. The second dimension of the 
address is an offset relative to the segment's base (the 
beginning of the segment). This serves to access specific 
locations within the segment. 

C. INTER -PRO CESS SYNCHRONIZATION ANT COMMUNICATION 

Utilizing the parallelism afforded by m^ultiple 
processors requires a mechanism for inter-process 
communication and synchronization. It is used for 
controlling the execution of processes and coordinating the 
sharing of data. 

The most widely used synchronization primitives are 
Dijkstra's semaphores [3] or Saltzer's Block and Vakeup [17] 
which were used in O'Connell and Richardson's original 
design [11]. However, the design decision was made to use a 
different mechanism which addresses the questions of 
confinement in a secure system. This is the synchronizat ion 
mechanism based on the eventcounts and sequencers of Reed 
and Kanodia [13] . 
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D. PROCSSSOP. MULTIPI2XING 



1 . lefinltion of Processor i^ult iplexing 

Processor mul t iplexinj? is a technique for sharin^^ 
scarce processor resources among an arbitrarily large number 
of processes. It is accomplished by simulating the existence 
of a larger number of virtual processors. This technique is 
widely used in conventional uniprocessor systems where it is 
commonly called multiprogramming. It seeks to maximize the 
use of the available hardware by automating control of 
process loading and execution. It also greatly increases the 
flexibility of a system allowing it to be effective in more 
complex and demanding applications. 

J. H. Saltzer [17] presented one of the fundamental 
works on the subject of processor multiplexing. His thesis 
provides an excellent treatise of the salient issues. 

2 . Processor Virtualization 

In order to effect processor multiplexing, the 
physical processor resources {those hardware devices that 
execute machine instructions) are virtualized by creating 
abstract processors called virtual processors. 

a. Virtual Processors 

Each ph^/’sical processor posseses some internal 
memory (registers) whose contents describe the processor's 
state. As part of the processor state, there is a 
Specification of the accessible address space- which contains 
the instructions and data used by the processor. 
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Virtual processors are simulations of 
processors. They can he viewed in essentially the same way 



as physical processors 


in 


that they 


execute 


the same 


instructions. However, 


the 


i ns truction 


set cf 


a virtual 



processor has been expanded to include some instructions 
which the physical processors do not directly have. These 
include ’’instructions" to "load" a process, certain 

synchronicat ion primitives, system service calls, etc. 

✓ 

Virtual processors exist only as abstract 

processors represented by a data structure. They are used as 

the vehicle for the control and manipulation of processor 

( 

resources . 

3 . Two-level Processor Multiplexing 

In this design, there are two levels of processor 
multiplexing. This design arose from the existence of 
multiple physical processors. Each of the levels address a 
distinct requirement. One level supports virtual processor 
management, that is, the prevision of inter-process 
synchronization. The other supports the management of 
physical resources by the operating system. 

This divides the requirements for multiplexing 
mechanisms into two parts. One of these addresses 
multiplexing virtual processors among processes and the 
other mul tiplexine: physical processors amon^ virtual 

processors . 
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a. The Traffic Controller 



The Traffic Controller represents the upper level 
of processor multiplexing (termed Level 2) and provides the 
mechanism for multiplexing virtual processors among 
processes. Thus it is responsible for inter-process 
synchronization. 

As an example, consider that a process, called A, 
will wish to synchronize its actions with another process, 
called B, such that process E will have to complete some 
task before A can continue execution. Thus A will execute to 
the point where it cannot proceed further and wishes to 
signal process E. When process B has finished its task, it 
must notify process A of its completion so that process A 
may then proceed. 

This inter-process synchronization is handled at 
the level of the Traffic Controller. When process A 
discovered that it could not proceed further, it ’Vave away" 
its virtual processor to some process that could run. The 
Traffic Controller suspended the execution of process A and 
a new process was bound to the virtual processor. In the 
same way, when 3 completes, viz., it has no more work to 
perform, it will also frive its virtual processor away. 

b. The Inner Traffic Controller 

The Inner Traffic Controller comprises the 
lower level of processor multiplexing (level 1) and provides 
the second set of multiplexing functions. It multiplexes the 
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physical processor among one or more virtual processors. 
While the virtual processors have identical capabilities, 
the physical processors may differ in their capat i li ties , 
viz., they may have different attached I/C devices, 
different local memory sizes, etc. The Inner Traffic 
Controller must manage the physical resources in such a way 
that the user is unaware of these differences. In 
particular, the system's interrupt system is managed by the 
Inner Traffic Controller. 

If a user process calls upon some system service, 
such as disk I/O or I/O for a real-time sensor, it must wait 
for that service to he completed before it can proceed. The 
performance of a system service is considered to be part of 
the requesting processes. However, it may actually be 
supported by another virtual processor. To control this 
interaction the Inner Traffic Controller orcvides the 
required inter-virtual processor synchronization mechanism. 
In particular, a physical system interrupt is directly 
transformed into a synchronization signal to a waiting 
virtual processor. This structure is particularly important 
for the support of real-time processing. 

4. Processor Multiplexing Strategy 
a. Process State Transitions 

Figure 1 illustrates the state transitions of a 
set of processes as a virtual processor is multiplexed among 
them. Some eligible process (one which is in the ready 
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state) is scheduled to run and is hound to the virtual 
processor. At this time, the process makes the transition to 
the running state. As far as the process is concerned, once 
it enters the running state, it is executing. 

At some point in its execution, the process may 
desire to block itself or signal another process. If it 
blocks itself (enters the blocked state), it will give up 
the virtual processor to which it is presently bound and 
will be out of contention ■ for processor resources. It will 
remain in the blocked state until some other process signals 
it (thus making the transition back to the ready state). If 
the process signals other processes, it will transition from 
the running state back to the ready state from which it may 
be scheduled to run again. In doing so, it allows the 
Traffic Controller to possibly give the virtual processor to 
some higher priority process which may be ready to run. 
b. Virtual Processor State Transitions 

Figure 2 illustrates the state transitions made 
by virtual processors as a physical processor is 

multiplexed. This diagram is very similar to that of Figure 
1. However, these transitions are not directly observeable 
by processes (except as differences in execution times) as 
virtual processor state transitions result from the 

management of physical resources by the operating system. 

In Figure 2, it can be seen that a running 
virtual processor can transition to the waiting state or the 
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ready state. The transition to the waiting state occurs when 
a virtual processor must wait for completion of some system 
service (analogous to the blocking of process A in the 
example given in paragraph a). While in the waiting state, 
the virtual processor is out of contention for processor 
resources until another virtual processor signals it to 
continue. While in the ready state, the virtual processor is 
in contention for processor resources and so may be 
scheduled to run on the physical processor. 
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PROCESS STATE TRANSITIONS 
Figure 1 




VIHTUAI PROCESSOR STATE TRANSITIONS 
Figure 2 
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III. MrJLTIFEOCESSOR ARCEITECTURE 



A. HARDVAE? REQUIRE'^ENTS 

One of the principal design <?oals of the systetp design 
was to provide for configuration independence. Therefore, 
the operating system imposes hut a few constraints on the 
hardware that are noted here. 

1 . Shared Global Memory 

The operating system maintains system-wide control 
data access! hie to each of the processors via shared 
segments. The communication path utilized for sharing this 
data is shared memory. Thus some shared memory must he made 
available to each microcomputer in such a way as to allow 
Independent access at the level of single memory references. 

2 . Multiprocessor Synchronization Support 

There must exist some hardware-supported 
multiprocessor synchronization primitive. This can he any 
form of an indivisible read-alter-rewr i te memory reference. 
This capability is required to implement global locks on 
shared data to prevent race conditions as the physical 
processors attempt to asynchronously manipulate shared data. 

3 . Inter-Frocessor Commiunicat ion 

Some method of communication between physical 
processors must be provided. This is satisfied by an ability 
to generate interrupts between the physical processors. This 
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capability is required for the itrplerrentation of preen^ptive 
scheduling . 



B. HARDWARE CONEIGURATION 

1 . System Configuration 

The hardware suh-system is configured as a 
multiprocessor [l] . The system consists of a number of 
single hoard microcomputers and a global memory module 

connected by a single snared bus. The system differs from 

* 

conventional multiprocessors in that each of the 

microcomputers possesses its own local memory. The global 
memory module is connected directly to the system bus and is 
the only physical memory resource which is shared by all of 
the processors. The general configuration is shown 

t 

schematically in Figure 3. 

2. Specific Hardware Employed 

The particular hardware selected for this 

implementation is based on the INTEL S6/12A single board 
microcomputer [6]. This microcomputer utilizes the INTEL 
S086, a 16-bit general-purpose microprocessor capable of 
directly addressing a total of 1 mega-byte of physical 
memory. 

a. The 80S6 Microprocessor 

The ££S6 does not support the notion of explicit 
segmentation. In the S086, addressing is segment-like in 
that base and offset addressing is used. The offsets are 
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formed relative to one of the four segment "base registers of 
the 8086; 1) the Code Segment Register, used for addressing 
a pure segment containing executable codet 2) the tata 
Segment Register, used for process local data, 3) the Stack 
Segment Register, used for the per process stacks, and 4) 
and the Extra Segment Register, typically used for external 
or shared data. 

In the £066, a segment can range anywhere up to 
64 kilo-lytes in length. Segments can he placed anywhere 
within the 1 me^a-hyte address space of the £086 as long as 
the segment base is placed on an even hexadecimal memory 
address. Segment access and hounds checking are not 
supported. Although there is no general segmentation 
hardware, this design effects a segmented address space 
through a combination of operating system support and system 
initialization conventions described in a companion thesis 
by Ross [16] . 

b. The 86/12A Single Board Microcomputer 

The E6/1P.A is a complete computer capable of 
stand-alone operation used as the basic processing node of 
the multiprocessor. It is a commercial product which 
satisfies the three basic hardware requirements for this 
operating system. First, possessing a system bus interface, 
each microcomputer is capable of independently accessing a 
global shared memory via the system bus. Secondly, the 8036 
CrU supports multiprocessor synchronizaton directly with an 
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indivisitle tes t-i^nd-se t semaphore instruction performed 
under tus lock. Lock semaphores reside in the shared e:lohal 
memory since the system tus must he locked to ensure that 
this instruction operates correctly. Thirdly, preempt 
interrupts can he generated ty using the parallel I/O ports 
provided on each microcomputer. This requires connecting the 
microcomputer's parallel I/O ports to the system interrupt 
structure . 

c. Preempt Interrupt Hardware Connection 

As with most microprocessors, the 8CS6 itself 
does not possess the capability to directly ^generate 
interrupts destined for other devices (the devices of 
interest here are other processors). The system interrupt 
lines are accessible through a jumper matrix [6] located on 
the microcomputers. The parallel I/O port output of each 
ISBC S6/12A is connected to this interrupt jumper matrix. 
Preempt interrupts «re then generated simply by outputting a 
single word through the parallel port onto the system 
interrupt lines. The connection is shown in Figure 4. 

Note that only a single interrupt line is 
actually required to implement system-wide preempt 
interrupts. In this implementation, four lines are used. 
This provides four unique interrupt lines. If more than four 
processors are used in the system, then these lines are 
multiplexed (viz., several processors share an interrupt 
line) . 
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d. The System Bus 

The Intel MULTIBUS [6] is utilized as the system 
hus . It is a widely used commercial product with a published 
set of standards. This hus is specifically designed to 
support multiple processors and is fully compatible with the 
microcomputers used. It is utilized without modification. 

C. EAR EW ARE ASSESSMENT 

The commercially available 66/12A single board 
microcomputer was chosen because it was specifically 
designed to provide support for multiple processor systems. 
In using the operating system described in the next chapter 
to manage the microcomputer's physical resources, this 
microcomputer is entirely suitable for use as a basic 
processing node of an effective multiprocessor system. 
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IV. DETAILED SYSTEM DESIGN 



A. STRUCTURE OF TEE OPERATING SYSTEM 

This operating system provides a mul tipro^rammed 
multiprocessor system with segmented process address spaces 
using the hardware described in Chapter III. The operating 
system is structured as a hierarchy of three levels [11] , as 
follows : 

level 3: Supervisor 

Level 2: Traffic Controller 

Level 1: Inner Traffic Controller 

The Inner Traffic Controller (Level 1) forms the 
bottom level of the hierarchy. It is "closest" to the 
hardware and encompasses the major machine-dependent aspects 
of the system. The Inner Traffic Controller multiplexes the 
physical processor amongst a pool of more numerous virtual 
processors . 

Residing at the next level (Level 2) is the Traffic 
Controller, which is responsible for multiplexing virtual 
processors among a larger number of user processes competing 
for resources. The user-accessible inter-process 
communication and synchronization primitives (Advance, Await 
and Ticket) provided at this level allow the user to easily 
address complex system-wide inter-process synchronization 
requi rements . 



34 



The Supervisor resides at the topmost level (level 
3). The Supervisor's purpose is to provide common services 
for user processes. In this implementation, it only provides 
a simple higher order language interface to the kernel hy 
having a single entry point into the kernel. 

3. DISTRIBUTING TEE OPERATING SYSTEM 

One of the primary concerns in any multiple computer 
system is the issue of performance. In this type of system, 
a multiprocessor with a single shared system hus, the most 
glaring potential bottleneck is the system hus. It then 
becomes highly desirable to minimize accesses to this 
resource that must be shared by all of the microcomputers. 

In terms of the design, the described system is a 
distributed operating system patterned after Multics [12], 
In particular, the segments of the operating system kernel 
are distributed as part of the address space of each 
process. In terms of the implementation of this system, the 
performance issue is addressed by physically distributing 
copies of the kernel in the local memories of each of the 
microcomputers. This allows high-speed access to kernel 
functions without necessitating use of the system bus for 
code fetches. 

Thus each computing node can be regarded as 
semi-autonomous in that each of the processors schedule 
themselves but are still centrally controlled by the set of 
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system-wide data tatles. There is no concept of a 
master-slave relationship amon? individual microcomputers, 
nor are individual kernel functions divided up among them as 
is more often done. Rather the entire kernel is distributed. 



C. REAI-TIME PROCESSING 



Real-time processing involves the performance of 
time-critical processing often related to the control of 
external devices. This application requires that some 
mechanism be employed to ensure that time-critical 
processing is given immediate attention. 

The hardware-supported process preemption mechanism 
employed in the system provides the rapid response required 
for real-time processing. The priority-driven preemptive 
scheduling technique used provides for expeditious handling 
of processes which perform time-critical functions. These 
processes are assigned high priorities so that the system 
will preempt other processes of lower priority that may be 
running. Thus when one of these high-priority processes is 
signalled, it can be immediately scheduled and gain control 
of processor resources. 



D. PROCESS ADDRESS SPACES 

The address space of a process is a set of PL/M-66 
segments: procedures (code), local variables (data). 



36 



external data (shared data), and stack [12,13]. Physical 
memory is allocated to the segments of a process in such a 
way as to limit system bus contention, as discussed hy Boss 
[16]. In this system, the stack is a key element in the 
management of processes. 

1 . The PI/M-S6 Stack 

Intel's high order language PL/M-66 [5, If] utilizes 
stack segments to implement per process stacks. Addressing 
of stacks is accomplished ty using three of the £(266's 
registers as shown in Figure 5. The Stack Segment (SS) 
Register contains the base location of the stack segment in 
memory. The Stack Pointer (S?) Register addresses the 
current top of the stack as an offset from the base of the 
stack Segment, (the value in the SS Register). The Base 
Pointer (BP) Register also holds an offset from the SS 
Register and is used to establish procedure activation 
records [7 , 6 , 9] . 

2. The S,tack as the Address Space Bescriptor 

In this system, the per process stacks are used to 
maintain process state information. This includes the 
current execution point (when the process is not actually 
running), the type of return from the kernel required for 
the process (normal or interrupt'! and the locations of the 
code and data segments. This allows the system to swap in a 
new address space (viz., do a context switch) by changing 
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the value in the SS Resiister, which is thus used in a rranner 
somewhat analogous to the Multics Descriptor Base Register 
[ 12 ]. 



Figure 6 shows how this information is stored in the 
stack while a process is not actually running on a physical 
processor. The Base Pointer, Stack Pointer and Return Type 
Indicator are stored in reserved locations at the very 
beginning of the stack segment. 

In order to identify the stack segment, and thus 
access the address space of a process, the stack segment 
base address is used in a dual role. First, a unique base 
address is assigned to the stack of each process which 
provides a unique segment for each stack. This base address 
is used for addressing locations within the stack. Secondly, 
the base address serves as a descriptor for the address 
space of each process. Thus the binding of a processor is 
changed from one process to another "merely" by chanf^ing the 
base address, viz., changing the value in the Stack Segment 
(SS) Register. 



E. system PROCESSES 

System processes make up the non-di stributed kernel. 
Non-distributed refers to the fact that these processes are 
not distributed as part of each process' address space. 
Rather they represent various system services. System 
processes are used for the management of hardware 
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and execute asynchronously with respect to user processes. 
In this desif^n, all system processes are permanently hound 
to dedicated virtual processors. 

1 . The Idle Virtual Processor 

The idle virtual processor provides the physical 
processor with a consistent state when no other virtual 
processor is ready to he run. The idle virtual processor 
assures that physical processors always have some valid 
process address space to execute in, although in this case 
it is only an idle process that performs no useful work. 

This is assumed hy creating for each physical 
processor a dedicated idle virtual processor. The idle 
virtual processors act as "default" that will only he run 
when no other runnahle virtual processors are found. 

F. SYNCFRCNIZATION 

Synchronization is required at two levels in this 
system: between processes (at the Traffic Controller level) 
and between virtual processors (at the Inner Traffic 
Controller level). Both levels use the eventcount and 
sequencer mechanisms [13] described below. 

1 . Sventcounts 

Eventcounts are used in this system to allow 
processes to arbitrate access to shared resources. 
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An eventcount is defined ty Reed to be: 

"an object in the system that represents a class of events 
that will eventually occur." [14] 

Each eventcount represents a distinct class of events. An 
eventcount is associated with seme type of event of 
interest, e.p., occurrence of a real-time interrupt, a 
buffer becoming full, a data segment being read or written 
into, etc. Eventcounts are implemented as sets of positive 
integers from 0 to infinity (the limit is actually 65,536 
using PL/^-86 "word" variables which is "adequate" for the 
applications anticipated) and are used to keep track of the 
total number of such events that have occurred. 

Three operations are defined on eventcounts. The 
value of an eventcount may be obtained by the READ 
operation. This returns the present value of the eventcount 
as a positive integer k. From this value, one nay infer that 
events 0 to k have already occurred. 

The AWAIT operation allows a process to suspend its 
own execution (enter the blocked state) until a specified 
event has occurred, viz., the eventcount reaches the value 
specified. The effect is the same as the conventional Block 
operation or Dljkstra's "p" operator. 

An ADVANCE operation is performed by a process when 
an event has occurred. It increments the value of the 
eventcount by one to reflect the occurrence of the event. 
This has the effect of signalling the event's occurrence to 
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other processes which were waiting for it hy virtue of 
having previously performed an AWAIT operation. The effect 
of an AEVANCi operation is essentially the same as a Wakeup 
operation or Dijkstra's "v” operator. 

The eventcount signalling mechanism has an automatic 
broadcast effect which offers an advantage in parallel 
processing. This broadcast capability allows the 
simultaneous signalling of several processes which otherwise 
would would have to be signalled sequentially. 

2. Sequencers 

There are many situations where accesses to shared 
resources must be totally ordered. Eventcounts alone are not 
sufficient to accomplish this. To provide the capability for 
mutual exclusion, another type of object called a sequencer 
[13] is employed. A sequencer is implemented as a positive 
integer ranging in value from 0 to infinity (as with 
eventcounts, the limit is 65,536). However, a sequencer is 
used to provide total order to the occurrence of events. 
Initially a sequencer has a value of 0. The value increases 
by one each time a TICKET operation is performed on it. 
TICKET is the only operation defined on a sequencer. TICKET 
returns a unique monotonically increasing value with each 
call. Thus, a set of events can be totally ordered by the 
TICKET operation. 
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3 . Inter-Process Synchronization 



Access to shared resources is easily controlled by 
using eventcounts and sequencers in concert, as shown in the 
following "producer /consumer" example [13] . 

Consider that some hypothetical consumer 'process 
called Printer uses a single input buffer in which it finds 
information to be processed (output to the printer). There 
are also an unknown number of producer processes called 
PPOCl, PP.0D2, etc., which have information that they want 
Printer to output for them. Obviously, with a single buffer, 
only one of the processes can use the buffer at any one 
time. The solution uses one sequencer and two eventcounts to 
properly mediate access to the buffer using mutual 
exclusion. 

The sequencer Turn is used by the producer processes 
to synchronize their use of the input buffer. The 
eventcounts Full and Empty are used to synchronize with 
Printer. Each of the producer processes will execute the 
program shown below. 



PP.ODl, PP0D2, etc. /* 
EO; 

T = TICKET (TURN); /<' 

/■if- 

AWAIT (EKPTT,T); /- 

! /* 

ADVANCE (FULL); 

/- 

end; /- DO "7 



Producer programs */ 

Get a "ticket" (turn) 
for the buffer *^7 

Wait for buffer ready */ 

Write into the buffer */ 

Signal Printer that •"/ 

there is work to do */ 
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Each of the producer processes first performs a 
TICKET operation on the sequencer Turn to obtain a "ticket" 
for the buffer. Each time TICKET is called, the variable T 
of the calling producer process will receive a unique value. 
This value is then used by the producer process as an 
argument for the call to AWAIT. It is the event (value of 
the eventcount EMPTY) for which the process will wait. When 
that event does occur (the value of Empty, which is advanced 
by Printer, reaches the value specified in the call to 
AWAIT) the process will be unblocked and may then proceed to 
use the buffer. When it has finished, the process will 
perform an ADVANCE operation on the eventcount Pull to 
signal Printer that there is information in the input 
buffer. Since each producer process uses the same sequencer, 



only one of them at a time 


will 


access the buffer. 




The consumer process 


Printer is programmed 


as 


follows . 








PRINTER 


/- 


Consumer program 




DO I = 1 TO 65536; 


/❖ 


Essentially forever 


*/ 


AWAIT (FULL, I ) ; 


/❖ 


Wait for a message to be 






/■" 


deposited in the buffer 


❖ / 


• 

• 


/- 


Perform output function 




ADVANCE(EMPTT) ; 


/- 


Notify waiting processes 






/« 


that the buffer is now 


/ 

'•V 




/* 


available 


/ 

'•V 



end; /- DO ■■■/ 

The Printer process synchronizes on the eventcount 
Pull (it waits until Full is advanced by some producer 
process that has finished using the buffer). After Printer 
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finishes with the buffer, it performs an AD7ANC2 operation 
on the eventcount Empty, This notifies the producer process 
that is "next in line" that the buffer is now available for 
its use . 

G. THE INNER TRAFFIC CONTROLLER 
1 . General Description 

The Inner Traffic Controller is the physical 
resource manager. It is responsible for physical processor 
multiplexing. Its principal data base is a table known as 
the Virtual Processor Map. 

Each physical processor has its own fixed set of 
virtual processors used in multiplexing. The Inner Traffic 
Controller is primarily concerned only with this set of 
virtual processors. However, the performance of system-wide 
synchronization requires access to the rest of the virtual 
processors as well, so that signals may be sent to other 
physical processors. This is accomplished by maintairing the 
Virtual Processor Map as a central data base containing 
entries for all of the virtual processors in the system. 
Making it globally available facilitates communication 
between virtual processors on a system-wide scale. The 
Virtual Processor Map fields are diagrammed in Figure 7. 

The State field reflects the present state of the 
virtual processor and can be any of ready, running, waiting, 
or idle. A ready virtual processor is bound to a process and 
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is in contention for the physical processor. The running 
virtual processor is that virtual processor which is 
actually executing a process on the physical processor. The 
waiting state reflects physical resource management. The 
idle state is assumed by a virtual processor which has no 
process bound to it. The idle state prevents the assignment 
of useless (idle) work to a physical processor. 

The Priority field of the virtual processor is used 
in scheduling. The highest priority runnable virtual 
processor is selected to run. This priority is determined by 
the priority of the process bound to the virtual processor. 

The System Eventcount Identifier and System Event 
Awaited fields are used in system level synchronization. 

The Stack Segment Register Value field defines the 

\ 

address space of the bound process. It holds the process 
address space descriptor. The execution state of the process 
is stored in the stack when the process is not actually 
running. This is the value which is required to access the 
address space of the process, viz., it is changed to swap 
processes . 

The Preempt Pending Flag is used for preemptive 
scheduling. It serves to virtualize a hardware interrupt 
sent to the physical processor. 

2 . Virtual Processor Scheduler (7p_Scheduler ) 

This module is responsible for making the scheduling 
decisions for virtual processors. It selects the highest 
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priority virtual processor from among the physical 
processor's assigned set of virtual processors and schedules 
it. Note that there are two distinct entry points to 
Vp_Scheduler . 

The normal call entry point is used by other Inner 
Traffic Controller modules to activate Vp_Scheduler when a 
virtual processor gives up the physical processor on its 
own. The preempt interrupt entry point is used in response 
to a hardware preempt interrupt from another physical 
processor . 

For a normal call, Vp_Scheduler sets the 
Vp_Scheduler return type flag to indicate that a normal 
call-return sequence is to be followed for the executing 
process. The Vp_Scheduler return type flag is used to keep 
track of the mode of entry into Yp_Scheduler for the 
process . 

Vp_scheduler next searches through the fixed set of 
virtual processors for the highest priority ready virtual 
processor. In this design, the definition of ready includes 
the combination of an idle state and a pending virtual 
preempt interrupt. This allows an idle virtual processor to 
run so that it may field the interrupt and bind to a new 
process. The idle process that was bound to the virtual 
processor was essentially useless up until this point. It 
now provides an address space for ^the virtual processor to 
execute in when binding to a new process. 
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Paving selected some eligible virtual processor, 
7p_Scheduler proceeds to bind the selected virtual processor 
to the physical processor. It begins by unbinding the 
currently running virtual processor. In doing so, the 
Vp_Scheduler return type flag, the Stack Pointer Register 
value, and the Rase Pointer Register value are saved in 
known locations on the process' stack. The process' 
execution state had already been saved. 

Binding the selected virtual processor is be^un by 
changing the Stack Segment (SS) Register value to that of 
the selected virtual processor. Once this change has been 
made, execution has actually swapped to the new process 
address space. Binding is completed by retrieving the 
previously saved Vp_Scheduler return type fla? for the new 
process, the Stack Pointer Register value, and the Base 
Pointer Register value from the newly acquired stack. 

The last step is to actually check the Vp_Scheduler 
return type flag to determine the proper type of return to 
execute from lTp_Scheduler for this process. If a normal 
call-return is indicated, a normal return will be executed 
back through the calling module. Otherwise, if a preempt 
interrupt return is indicated, an interrupt return will be 
executed and Check_Preempt will see if a virtual preempt 
interrupt is pending. If a preempt interrupt is found to be 
pending, the Traffic Controller's preempt handler will be 
i nvoked . 
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a. Internal Modules 



There is one internal module for the Virtual 
Processor Scheduler (Vp_Scheduler ) . It is used for the 
generation of hardware preempt interrupts. 

(1) Hdwr_Int 

This module is called hy the Inner Traffic 
Controller's interface modules Itc_Advance and Send_Preempt . 
It is called with one argument, a physical processor 
identifier. It then generates the required hardware 
interrupt . 

3 . Inner Traffic Controller Interface Modules 
a. Ioad_Vp 

This module performs the "binding of a new 
process to a virtual processor. It is called "by the Traffic 
Controller Scheduler when a process has "been selected for 
the virtual processor. Load_Vp requires two parameters, the 
priority of the new process and the address sp^ce descriptor 
(the Stack Segment Register value). It then swaps in the new 
process onto the virtual processor which is currently 
running. Load_Vp only operates on the virtual processor 
which is running on the physical processor. 

Binding is accomplished hy updating the Virtual 
Processor Map. The Inner Traffic Controller utility function 
Itc_Ret_Vp is used to obtain the identity of the running 
virtual processor. When complete, the virtual orocessor will 
have a new priority and process address space descriptor. 
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Load_7p completes ty calling Vp_Scheduler to schedule the 
virtual processor. 

h. Idle_Vp 

This function is Load_Vp's counterpart. It is 
called "by the Traffic Controller Scheduler in the event that 
a runnahle process is not found for the virtual processor. 
In this case the virtual processor will be idled (enter the 
idle state) and the Idle Process will be bound to it. In the 
Virtual Processor Map, the virtual processor's state will be 
marked as idle, the address space descriptor for the Idle 
Process will be entered in the Address Space of Bound 
Process field, and the virtual processor will be given a 
high priority. The idle state ensures that the idle process 
is not actually run (the virtual processor now has a high 
priority) by taking the virtual processor entirely out of 
contention for the physical processor. 

At some later point, the virtual processor may 
be placed back in contention for resources. This will occur 
when the virtual processor is preempted. With the 
combination of an idle state and a pending preempt, the 
virtual processor is treated as a high priority ready 
virtual processor. This allows the virtual processor to keep 
busy by expediting its binding to a process. 

lastly Idle_Vp calls Vp_Scheduler in order to 
give up the physical processor. 
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c. Itc_Ret_Vp 



This is a "utility" function which is used by 
Inner Traffic Controller and Traffic Controller tnodules. 
Itc_?et_Vp searches the Virtual Processor Map and determines 
the identity of the virtual processor that is currently 
running on the physical processor. It simply checks for the 
virtual processor amon^ the virtual processors assigned to 
the physical processor which is in the running state. 
Itc_Ret_Vp then returns its result as a function value, 
(viz., as in PL/M) in the AX ( accumula ter ) register. It will 
return either the identity of the virtual processor (the 
virtual processor's index in the Virtual Processor Map) or a 
"not found" error code. 

d. Check_Preempt 

This module is called by Vp_Scheduler during the 
execution of an interrupt return. It checks for a pending 
preempt interrupt meant for the virtual processor, which has 
been selected to run by Vp_Scheduler , by checking the 
virtual processor's Preempt Pending Flag in the Virtual 
Processor Map. If the Preempt Pending Flag is set, 
Check_Preempt will reset it and call the Traffic Controller 
module Tc_Pe_Eandler . 

The module continuously loops as lone as it 
finds the Preempt Pending Flag set. This is to ensure that a 
new preempt interrupt which might arrive before servicing of 
the last preempt is not lost. 
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e. Send_Preempt 



This module is responsitle for actually sending 
preempt interrupts. It is called hy the Traffic Controller 
Advance module. Send_Preempt requires two arguments, the 
identity of the virtual processor which is to he preempted 
and the physical processor to which that virtual processor 
is assigned. 

Send_Preempt sets the virtual processor's 
Preempt Pending Flag and calls Fdwr_Int to generate a 
hardware interrupt for the physical processor. Hdwr_Int is 
not called if the virtual processor to he preempted is 
assigned to the physical processor which is executing 
3end_Preempt , (viz., a physical processor will not issue a 
hardware preempt interrupt to itselfK 
f. Itc_Await 

Itc_Await is one of two functions which 
implements inter-virtual processor synchronization within 
the kernel. It is not accessible to user processes, hut is 
used hy the system in the management of physical resources. 
It allows a virtual processor to wait for the occurrence of 
a system event. 

It expects two input arguments, the index of the 
eventcount in the System Fventcount Table and the value of 
the event to he awaited. 

Upon being invoked, Itc_Await locks the Virtual 
Processor Map. It then checks the current value of the 
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eventcount , obtained from the System Iventconnt Table, 
against the value ,»:iven in the call. If the present value of 
the eventcount is found to be less than the value of the 
input ar^?ument, then the virtual processor will enter the 
waiting state and give up the physical processor. 

The virtual processor's entry into the waiting 
state will be reflected in the Virtual Processor Map. The 
input arguments will be entered in the Identity of 
Eventcount Awaited and the Value of Eventcount Awaited 
fields. Finally, the virtual processor will relinquish the 
physical processor by calling Vp_Scheduler . Upon a return 
from Vp_Scheduler , the Virtual Processor Map will be 
unlocked. 

g. Itc_Advance 

Itc_Advance is used within the kernel to signal 
the occurrence of system events. It is used with Itc_Await 
for synchronization between virtual processors. It accepts 
one input argument. This is the index in the System 
Eventcount Table of the eventcount to be advanced. 

Upon being invoked, the Virtual Processor Map is 
locked. The System Eventcount Table is then accessed and the 
indicated eventcount's value is incremented by one. The 
resultant value is then compared against the events waited 
for by other virtual processors which are synchronizing on 
the Same eventcount. Those virtual processors whose Value of 
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Event Awaited fields are less than or equal to the current 
value of the eventcount are made ready. 

Itc_Advance then calls Vp_Scheduler to schedule 
the virtual processor. The Virtual Processor Map will he 
unlocked upon a return from Vp_Scheduler . 

H. THE TRAFFIC CONTROLLER 
1 . General Description 

The Traffic Controller manages the execution of user 
processes. It presents to the user a system of one more 
virtual processors on which to execute his processes. 

The Traffic Controller's primary data "base is the 
Active Process Table, shown in Figure 8. The entry for each 
process in the Active Process Table contains sufficient 
information about the process to enable a virtual processor 
to be bound to and execute it. The fields of the Active 
Process Table are explained below. 

The State of a process can be either ready, running 
or blocked. A ready process is one which is not yet bound to 
a virtual processor but is ready to do so. A running process 
is one which is bound to a virtual processor and, as far as 
the process is concerned, executing. The blocked state 
reflects inter-process synchronization. A process enters the 
blocked state when it realizes that it can no longer proceed 
and wishes to give up its virtual processor to wait until 
another process awakens it. 
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The Affinity field specifies the physical processor 
that the process must execute on. In this system, this field 
indicates the specific microcomputer on which the process is 
currently loaded. 

The Identity Of Bound Virtual Processor serves to 
identify the virtual processor, if any, that the process is 
currently "bound to. 

The Priority specifies the priority of the process. 
In this system, priorities ranee in value from 0 to 255, 
with a priority of 0 being the highest. 

The Loaded List Thread field serves to implement the 
Loaded List of ready and running processes. It contains a 
pointer to the next process in the Active Process Table 
which is loaded on the same microcomputer as this process. 
The loaded list is ordered by the priorities of the 
processes. Thus, this field contains either a pointer to a 
process whose priority is less than or equal to that of this 
process or a nil pointer (viz., the last process on the 
Loaded List). 

The Value Of Eventcouat Awaited reflects the event 
for which the process has blocked itself. It contains the 
value that the process is waiting for the eventconnt to 
reach , 

The Block List Thread is used to implement the 
Blocked List. This is a per eventcount list of processes 
which are waiting on the eventcount. 
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The Address Space Descriptor field contains the 
process" address space descriptor. This is the identity of 
the process' stack which contains execution point 
information. The value used here is the base location in 
memory of the stack segmentt viz., the Stack Se^rment ^SS) 
Register value. 

2. Process Scheduler (Scheduler) 

Scheduler works in essentially the same way that the 
Inner Traffic Controller's 7p_Scheduler does. However, 
Scheduler works with processes. Scheduler can he called hy 
Advance, Await, Tc_Pe_Fandler , Create_Evc, Create_Seq, and 
Create_Process. 

It selects the highest priority ready process from 
the microcomputer's Loaded List to he hound to an available 
virtual processor. Scheduler works only with the processes 
which are runnahle on its own physical processor usins’ the 
fixed set of virtual processors for that physical processor. 

If Scheduler finds a runnahle process, the Inner 
Traffic Controller module Load_Vp is called to hind the 
selected process to the running virtual processor. 
Alternatively, if a runnahle process is not found, the 
virtual processor will he idled (hound to the Idle Process 
and placed in the idle state) hy a call to the Inner Traffic 
Controller module Idle_Vp. 

In its present form. Scheduler has only one entry 
point, a call entry point. There is no interrupt entry point 
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as there is in Vp_Scheduler . This was done as an expedient 
in this design effort. It is desireatle to provide the 
second entry point so that the two schedulers have parallel 
structures. Because there is no interrupt entry point, there 
is a loop between the Inner Traffic Controller and the 
Traffic Controller for the handling of preempt interrupts. 
This is due to the call from the Inner Traffic Controller's 
preempt handler Check_Pre_Empt to the Traffic Controller's 
preempt handler Tc_Pe_Handler . 
a. Internal Modules 

There are two "utility” modules internal to the 
Scheduler that are used only by Traffic Controller modules. 
They are used to simplify the handling of eventcounts and 
Sequence rs . 

(1) Locate_Evc. This "utility” returns the index 
of an eventcount in the Pventcount Table. It is called by 
Advance, Await and Ticket with (a pointer to) the name of 
the eventcount. Locate_Pvc then attempts to match the name 
given to it with one in the Eventcount Table. If a match is 
found, it returns the index to the caller in the AX 
(Accumulator) Register as a function value (viz., as in 
PI/M) . 

(2) Locate_Seq. This is the second Traffic 
Controller "utility” function. It works in exactly the same 
way that Locate_Evc does except that it searches for 
sequencers in the Sequencer Table rather than eventcounts. 
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3. Traffic Controller Interface Modules 



a. Await 

Await allows a process to suspend its execution 
pending the occurrence of a specified event. A^'AIT is called 
with two arguments, (a pointer to) the name of the 

eventcount and the value (of the event) to he awaited. 

Upon invocation. Await locks the Active Process 
Table and then calls the Inner Traffic Controller utility 
function Itc_Ret_Vp to obtain the identity of the running 
virtual processor. This is used in a search of the Active 
Process Table to identify the calling process. 

Once the calling process has been identified, 

f 

the current value of the eventcount is compared to the 
awaited value specified in the call. If the event has not 
yet occurred, (viz., the current value is less than the 
value to be awaited), then the process will enter the 
blocked state. The Value of Eventcount Awaited field in the 
Active Process Table is updated with the value awaited 
argument and the process is placed on the eventcount 's 
Blocked List. If the event has already occurred, (viz., the 
current value is greater than or equal to the value awaited 
argument), then the process is not blocked but is made 
ready. 

Await next calls Scheduler. The Active Process 
Table is unlocked upon the return from Scheduler. 
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fc. Advance 



Advance allows a process to signal the occurrence 
of an event. It updates the eventcount and signals those 
processes which had blocked themselves for this event. Thus 
Advance is responsible for preemption. 

Advance is called with one argument, (a pointer 
to) the name of the eventcount being advanced. 

It first locks the Active Process Table. Then the 
current value of the eventcount is incremented. The 
eventcount 's Blocked List is searched for processes which 
had previously blocked themselves for this value. As 
processes are found that should be awakened, they are made 
ready. An entry in a temporary array of physical processors 
is now made to flag the physical processor, in whose local 
memory the newly awakened process is loaded, for preemption. 
The awakened process is then removed from the eventcount 's 
Blocked list. 

Once all of -the processes to be awakened have 
been found. Advance determines which virtual processors must 
be preempted. This is done for each of the previously 
flagged physical processors by first assuming that all of 
the physical processor's virtual processors should be 
preempted. Then the decision is made as to which ones will 
not be preempted. This method greatly simplifies the 
algorithm. First a temporary list (array) of virtual 
processors is initialized to indicate a virtual preempt for 
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each of the virtual processors. The Loaded List is then 
searched to find those processes which should he running. 
The processes which should he running are those with the 
highest priorities that are in either the ready or the 
runninf? states. Assuming there are 2 virtual processors per 
physical processor used for multiplexing, the 2 highest 
priority ready or running processes in the loaded list 
should he running. Any lower priority processes that 
actually are running should he preempted. Advance determines 
which of the processes that should he running already are 
running and deletes their virtual processors from the 
preemption list (resets the preempt flag in the array). What 
will remain at the end are those virtual processors that are 
to he preempted. 

The next step is to actually issue the preempt 
interrupts. The temporary preempt list is checked and if a 
preempt is indicated for a virtual processor, the Inner 
Traffic Controller module Send_Preempt is called to actually 
issue the preempt. 

Advance next readies the calling process and 
calls Scheduler. Upon the return from the call to Scheduler 
the Active Process Table is unlocked, 
c. Ticket 

Ticket returns a unique sequencer value with 
every invokation. The value returned will always be one more 
than the last value returned. 
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It is called with one argument, (a pointer to) 
the sequencer name. When invoked. Ticket asserts the global 
lock on the Active Process Table, effectively locking the 
Sequencer Table. Ticket then calls Locate_Seq with the 
pointer to the sequencer name given to it as an input 

argument and gets back the index of the sequencer in the 

Sequencer Table. It then obtains the sequencer's value which 
is to be returned to the calling module in the AX 

(Accumulator) Register following standard PI/M conventions. 
Before returning, ticket increments the value of the 

sequencer and unlocks the Active Process Table. 

Note that Ticket does net call Scheduler like the 
other synchronization primitives Advance and Await. Ticket 
returns immediately from a call, 
d. Read 

Read returns the current value of an eventcount. 
It is called with one argument, (a pointer to) the name of 
the eventcount. 

When called. Read locks the Active Process Table, 
so as to lock the Eventcount Table. It then calls Locate_Evc 
to obtain the index of the eventcount in the Eventcount 
Table. With this index. Read obtains the value of the 
eventcount and returns the value in the AX (Accumulator) 
Register following normal PI/M conventions. Prior to 
returning. Read unlocks the Active Process Table. 



% 



64 



Tc Pe Handler 



e . 

This module serves as the virtual preempt 
interrupt entry point into Scheduler. It is called ty the 
Inner Traffic nontroller's Vp_Scheduler in the course of 
handling preempt interrupts. 

Tc_Pe_Handler calls Scheduler to find the highest 
priority ready process to tind to the pre-empted virtual 
processor. 

f. Create_Evc 

This module creates an eventcount for a user 
process. Create_Evc is called with one argument, (a pointer 
to) the name of the eventcount to he created. 

Upon being invoked, Create_Svc locks the Active 
Process Table, which effectively locks the Eventcount Table. 
It then calls Locate_Evc to determine whether or not the 
eventcount had already been created. This is to avoid making 
duplicate entries (since each process which will use the 
eventcount must declare at least the name). If the 
eventcount had not previously been created (viz., no entry 
is found in the Eventcount Table with the same name as given 
in the input argument) then an entry is made in the 
Eventcount Table. The name is copied into the Eventcount 
Table and the eventcount's current value is initialized to 
0. Otherwise, no entry is made. Lastly, it unlocks the 
Active Process Table prior to returning. 



65 



g. Create_Seq 

This module creates a sequencer for a user 
process. Create_Seq performs in exactly the same way as 
Create_Evc (paragraph f) except that it creates sequencers 
rather than eventcounts. 

h. Crea te_?rocess 

Crea te_Process provides the capability to 
dynamically create processes. It is called with one 
argument, a pointer to a process parameter "block: containing 
all the information necessary to initialize the process's 
stack and enter the newly created process into the Active 
Process Table. All of the process's segments had previously 
been loaded into memory by the system loader, Foss [16]. 

Create_Process first locks the Active Process 
Table. It then creates the initializaton stack frame. The 
process parameter block contains all of the initial register 
values (viz., initial values for all of the £l?e6's 
registers) for the process. These are stored in the 
initialization stack frame? the location of the stack is 
specified in the Process Parameter Block. The next step is 
to create the Active Process Table entry for the process. 
The affinity, priority and Stack Segment (SS) Register value 
are then entered in the Active Process Table. lastly, 
Create_Process determines where this process should be 
inserted into the Load List based on its priority. 
Create_Process inserts the process into the Load List (viz., 
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sets the Load Thread in the Active Process Tatle) 
immediately ahead of the first process it finds in searching 
down the Load^List whose priority is less than or equal to 
the newly created process. Finally, the Active Process Table 
is unlocked and execution returns to the caller. Note that 
the Scheduler is not called. 

I. THE SUPEHVISOE 

In a general-purpose operating system the Supervisor 
provides common services such as library routines, linkers, 
various development tools and a file sytem. It also acts as 
the interface between user programs and the kernel. 

1 , General Pescription 

At this state of the design, only one module resides 
at this level, a higher order language interface to the 
operating system kernel. This module (called the Gate) is 
constructed such that it is the only operating system module 
that tl\e user must link to his processes to access kernel 
functions . 

The Gate contains the actual linkages (viz., global 
procedure declarations) for all of the kernel functions. 
This allows the user to directly call on various kernel 
services without using absolute addresses that car. change as 
the kernel continues to be developed. This structure allows 
the users and the operating system developers to continue 
their work independently without requiring the users to 
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continually chanfe their programs to accornrroda te changes in 
the kernel. 

2 . Supervisor Invocation (The Gate) 

The Gate is actually a set of global (vi?., PI/^^ 
PUBLICS procedure declarations which the user programs can 
call directly. Each of the user accessible kernel fimctions 

i 

is represented hy one of these "procedures". In reality, 
they simply set up the required parameters and use a trap 
feature to effect the call to the "real" procedure of the 
same name residing in the kernel. 

The Gate is written in assembly language because of 
the stack manipulation that must be done to enable the trap 
handler to l) determine the correct kernel procedure to 
call, and 2) properly pass parameters to the kernel 
procedures. The trap handler in the kernel is an assembly 
language module as well. If the trap handler were written in 
PL/M, parameters would have to be somehow given to it 
explicitly prior to its calling on the kernel procedure. 
Since the trap handler is reached by an interrupt rather 
than a call, this is not possible. Instead, the parameters 
are moved on the stack to a position where they become 
parameters for the call by the trap handler to the kernel 
procedure . 

This has the effect of de-coupling the user from all 
of the operating system modules below the level of the 
Supe rvi son . 
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V. CONCLUSIONS 



A. SUMMARY OF RESULTS 

The principal goal of this effort is the developrrent of 
a multiple processor system. A parallel development effort 
in secure systems, Reitz [18], utilized the O'Connell and 
Richardson design as the basis for the kernel of a secure 
computer system utilizing the Zilog Z8OC0 microprocessor. 
The detailed designs of the kernels of both of these systems 
is nearly identical, at least at the level of kernel module 
interfaces. In both development efforts, no conceptual 
problems were encountered. Thus the O'Connell and Richardson 
design has been found to be consistent for multiple 
processors and secure computer systems. 

System initialization [16], introduced a number of 
design changes. Eowever, these had no adverse effect on the 
design or the system. Their integration is not a simple 
matter as they impact on the stack format, and the design of 
the process scheduler and virtual processor scheduler in 
that the accommodation of preempt interrupts is somewhat 
more difficult. 

Another of the objectives is to test the viability of 
utilizing general-purpose, commercial microcomputer systems 
as the basic building blocks of multiple computer systems. 
It has been found that sufficiently developed microcomputer 
systems are available in industry. Further, it was 
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determined that enouiRh hardware support ("busses, I/O 
devices, peripherals) is available to construct multiple 
computer systems without major hardware development efforts. 

The state of the art in microcomputer software 
development was found to he less amenable. Such useful tools 
as high level languages, assemblers, etc. are available but 
they are generally limited to use with uniprocessor 
developmental systems. Additionally, most commercially 
available software development tools are highly machine 
dependent. Specifically, they require low-level monitors or 
special hardware that are only available on a development 
system. Thus there is little hope of easily modifying these 
tools to run on a different system than was intended by the 
vendor, particularly since details of their structure and 
operation are proprietary, 

A. FURTHER RESEARCH 
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procedure "Lockset" [5]) is a spin-lock wita potentially 
sienificant impact on system bus traffic. This mechanism 
should be replaced by the Inner Traffic Controller 
synchronization primitives wherever possible to avoid the 
overhead of "busy-waiting". 

This detailed design is considered to be only a first 
step in the development of a general-purpose multiple 
microcomputer system. O'Connell and Richardson's design 
offers some exciting opportunities to pursue development 
efforts in the areas of secure computer systems and fault 
tolerance . 
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APPENDIX A - PROC-R A Mining 



A. INTRODUCTION 

This appendix is designed to he a practical introduction 
to programming methodology for this system. 

Because there are multiple processors, a nuirher of 
concepts and methodologies will necessarily he introduced 
which may at first he uncomfortable . This is especially true 
if one is firmly entrenched in the traditional concepts of 
the monolithic, sequential program structure. However, as 
one makes the transition to the concepts of process 
structuring, it will he seen to he a natural approach to the 
development of complex software systems. Additionally, it is 
essential to the effective use of multiple processor 
systems . 

Parallelism immediately presents the programmer with an 
entirely new set of complexities. He is not limited tc the 
strictly sequential execution of program statements in a 
single program. Exercising control over the order and timinf' 
of execution of multiple pro cesses becomes a major part of 
the programming effort. Inter-process synchronization, the 
mechanism by which processes are controlled, is the most 
difficult concept which the user will he required to deal 
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with. However, the synchronization primitives tuilt into the 
operating system are designed to make this as simple and 
straightforward as possible. 

It is assumed that the primary programming language for 
this system will be Intel's FL/M-36 [5, 10], This is a 
powerful, block structured high level language designed for 
systems programming. This appendix is written assuming that 
the reader will program in PL/M-66 and is familiar with its 
terminology and notation. All of the examples make use of an 
informal notation. 

E. THE PROCESS STRUCTURE 

Consider the rather typical PL/(^ program module of 
Figure 9. It contains three procedure declarations and some, 
mainline statements. Each of the procedures will execute 
when called from the mainline and, upon completion, will 
return control back to the mainline. 

A single program is what most users are familiar with 
and is a structure which can be dealt with easily. However, 
as the computing task grows to any real size and complexity, 
this single program grows equally large and complex. The 
result is a huge program with a myriad of procedures that 
can only be called sequentially to perform necessary 
functions. Thus this structure does not allow taking 
advantage of the performance ^^ain that parallel processing 
can offer. 
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Propran Module A: To; 

A1 : PROCEBURS /’••' Declaration '•'/ 

do; 



kmd; 

end; /* Procedure <11 */ 

A2: procedure; /* Declaration -/ 

do; 



END; 

end; /- Procedure A2 -/ 

A3: procedure; /* Declaration -/ 

do; 



end; 

end; /- Procedure A3 */ 

do; /* Begin Mainline */ 

CALL Ai; 

CALL A2; 

CALL Ao; 

end; /- Mainline ■-/ 
end; /■' Program Module A */ 



EXAMPLE PL/M-36 PROGRAM 
Figure 9 
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start 

Process ins: 




TFRP2 PROCESSES SXECETIMG SEQUENT I ALLY 
Pi, sure 10 



DSCIAPE NAMEK6) BITE DATA ('MAf"El%'); 



Byte array of 
length 6 to hold 
the name 



String constant 
name defined hy 
the user 



DECLARATION OF EVENTCOUNT AND SEQUENCER NAMES 

✓ 

Figure 11 
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The principal advantages of the process structure lie in 
the ability to utilize multiple processes and tc 
independently construct individual components of software 
subsystems, viz., processes. Rather than using a single 
process to accomplish the entire job as in figure P, the 
overall task can be partitioned and accomplished by a number 
of smaller cooperating processes. Each of these processes 
can be smaller than the single monolithic program and so is 
easier to design, implement and test. This allows entire 
processes (each a distinct program) to be developed and 
tested semi-independen tly in a manner similar to the 
development and testing of individual procedures in a single 
PL/M program. 

Control over processing functions is also much more 
flexible. One is not forced into a strictly sequential 

I 

series of procedure calls. Many processes can be allowed to 
execute in parallel, which can bring about dramatic gains in 
overall performance. 

Figure 10 is a simple example of the flow of execution 
in a system with three processes. The three processes 
perform exactly the same functions as the three procedures 
of Figure 9 and so bear the same names. In this example the 
processes execute sequentially, one after the other in a set 
order. Processing goes on forever in this loop . Process A2 
will only begin executing after it has been somehow 
"signalled" by process A1 . The same is true of process A5 
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whose execution is synchronized with process A2. Obviously, 
there must be some control mechanism that allows these 
processes to do this. 

C. INTEB-PROCZSS SYNCHRONIZATION yECKANISMS 

The ability to synchronize the execution of processes 
throughout the system, (irrespective of which microcomputer 
they are loaded on), is the cornerstone of the power and 
flexibility of this system. To accomplish this, process 
synchronization is based on the notion of events. 

1. Events 

An event is anything that one considers significant 
and can direct, in some fashion, the computer to respond to. 
As an example, consider a clock which indicates a time of 
twelve o'clock. The computer has no inherent conception of 
time. As far as it is concerned, time may be nothing more 
than a value in some register. In some way, then, time must 
be defined for the computer. This is accomplished by 
translating the occurrence of twelve o'clock into an event. 
When the event occurs, the computer recognizes that it is to 
respond in some specified manner. 

Events are defined so as to be very f^eneral in 
nature. They can be used to represent the completion of a 
program, as in the completion of process A1 in Figure 12 
which started tne execution of process A2. They can 
represent virtually anything of interest to the programmer. 
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at least anything that he can identify as hein;? of 
s i^ni f i cance . 

2 . Zventconnts and Sequencers 

Sventcounts and sequencers allow processes to 
synchronize with each other somewhat indirectly. To 
synchronize directly, a process would have to somehow 

identify the other processes with which it is synchronizing 
(viz., explicitly signal a process hy name). This would 
require the naming: of individual processes or some similar 
identification scheme. 

Rather than using a process naming scheme, the 
individual processes "agree", in a sense, to cooperate hy 
using a common set of memory objects called eventcounts and 
sequencers. In this way, even though the processes must know 
the names of the eventcounts and sequencers that they use, 
they are not required to know anything at all about each 
other's identities. In fact, a process need not even know- 
how many other processes will the synchronizing with it. 
This offers some advantages in parallel processing. 
Processes that synchronize with eventcounts do not have to 
know how many other processes will also use the same 
eventcounts. This means that fewer coding changes will be 
required when, for example, a single process is partitioned 
into several processes all executing in parallel. All of the 
"new" processes will synchronize on the same eventcour.t so 
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that no changes are required in the process that originally 
synchronized with the single process. 

Eventcounts are used to keep track of the occurrence 
of specific events. They are tnana^ed for the user hy the 
system. Eventcounts are implemented as FI/M-66 word 
variables ranging in value from 0 to 65536. Sequencers are 
also implemented as FL/M-66 word variables ranging in value 
from 0 to 65536. However, sequencers can be used to impose 
an order on the occurrence of events. They are thus used 
with eventcounts to provide for mutual exclusion. 

3. Sventcount and Sequencer Feclarations 

a. Declaring Sventcount and Sequencer Names 

Eventcounts and sequencers are named using a 
byte array of alphanumeric characters. The format for 
declaring an eventcount or sequencer name is given in Figure 
11. Note that the names are constants, not variables. Once 
declared, a name must not change. Sventcount and sequencer 
names consist of 5 characters followed by a per cent symbol 
(%). Note in Figure 11 that the name of the byte array must 
be the same as the string constant given in the FATA 
Initialization. This allows the user to reference the 
eventcount or sequencer by name and allows the operating 
system to identify it. 

Remember that the names of eventcounts and 
sequencers must be declared in exactly the same way in each 
PL/M-86 module in which they will be used. 
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t. 



Passing Fventcount and Sequencer Names 



When calling the operating system 

synchronization primitives, eventcount and sequencer names 
are always passed as rL/M-c6 location references using the 
"C=" operator. As an example, consider that a "byte array 
called "NAMEI” holds the strinp- ”NAME1%" (note that the 
symbol is only a delimiter and is not considered to he part 
of the name). To pass the name in a call to an operatine 
system synchronization primitive, then, the param;eter 
"GNAMEI” is used. With the pointer so given, the operating 
system can "read” the name directly from the array, 
c. Creating Eventcounts and Sequencers 

Before an eventcount or a sequencer is used, the 
operating system must he informed of its existence. This is 
accomplished hy a call to the operating system procedures 

CPEATEiSVC (for eventcounts) and CHEATE^SEC (for 
sequencers). The format of these operations is shown in 
Figures 12 and 13. There is only one argument for either of 
the calls, the pointer to the previously declared name. When 
created, an eventcount or a sequencer will always he 
initialized with a starting value of 0. 

4. Synchronization 

Eventcounts and sequencers are utilized hy means of 
a set of operations which may he performed on them. The user 
cannot directly perform operations on either eventcounts or 



CALL 



CALL 



CRSAT2$E7C(0NAME1); 



Kernel Pointer to 

function the head of the 
name pre-declared 

byte array holding 
the string name 



CHEATING AN EVE NT COUNT 
Eif?ure 12 



CHSATE$SEC(GNAME1 ); 

Kernel Pointer to 

function the head of the 
name pre-declared 

byte array holding 
the string name 



creating a sequencer 

Figure 13 
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sequencers, but rather calls on certain operating system 
primitives to do these for him. 

a. Operations on Eventcounts 

There are three operations that one can perform 
on eventcounts. They are ADVANCE, AWAIT and READ. ADVANCE 
and AWAIT are untyped procedures. READ is a value returning 
typed procedure (function call) that returns a FL/M-£6 word 
value to the calling process. 

An example of a READ operation is piven in 
Figure 14. The READ operation allows the user to obtain the 
current value of a specified eventcount. READ returns the 
eventcount's value in the AX Register (in accordance with 
normal PL/M-66 conventions). Thus a process calls READ with 
the name of the eventcount as the argument and gets back the 
eventcount 's current value. Note in Figure 14 that the 
current value of eventcount EVENT is returned to the 
user-defined word variable ”W0?.D$VARIA.5LE" . 

The AWAIT operation. Figure 15. is used by a 
process to block itself (suspend its execution) until the 
eventcount reaches the value specified in the call. A'WAIT 
requires two arguments, the eventcount name and the event 
(actually the value of the eventcount) to wait for. The 
value for which the process will wait must be a ?I/y-S6 word 
value. This allows the process to synchronize itself with 
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WORIiVARlAPLE = RiAD(G3?ZNTl ; 

TKS HEAD OPERATION 
Eigure 14 

CALI AWAIT(GEVENT ,VALUE$TOiAWAlT ) 

THE AWAIT OPERATION 
Fig’ure 15 

CALL AD7ANCE(GS7ENT) ; 

THE advance OPERATION 
' Figure 16 

WORD $VARI ABLE = T I CHET (GNAMEl ) ; 

THE TICKET OPERATION 
Fi.«?ure 17 



83 



other processes by waiting, for instance, until a set of 
data is ready for it to use. 

The AIVANCE operation, Figure 16, is used to 

signal the occurrence of an event. ADVAMCE only requires one 

/ 

argument, the name of the eventcount to be advanced. When it 
is called, it will cause the value of the eventcount to be 
incremented by one. The operating system will then proceed 
to unblock those processes that were waiting for the 
eventcount to reach the current value (by virtue of having 
previously called AWAIT). 

b. Operations on Sequencers 

There is only one operation that can be 
performed on sequencers. It is called TICKET, Figure 17. 
TICKET is a value returning typed procedure (function call) 
similar to the READ operation for eventcounts. However, 
TICKET returns to the caller a unique sequencer value. The 
current value of the sequencer is returned to th'e caller and 
then the sequencer is incremented by one for the nett caller 
time a TICKET operation is performed on it. This will be 
true irrespective of how many different processes perform 
the TICKET operations. In this way TICKET provides the 
totally ordered set of values for use by multiple processes 
in effecting mutual exclusion. 



5. Synchronization Examples 

a. Sequential Processing Example 

Figure IS provides a detailed example of how a 
process would he programmed to actually create and use 
eventcounts for synchronization. The program shown here is 
actually process A1 of Figure 10. 

Referring to the flow of control in Figure 10, 
it can he seen that process A2 will begin execution when 
signalled hy Al. Similarly process A3 will begin when 
signalled hy A2. Finally, when A3 signals its completion, 
the "loop” starts over again with process Al . This is 
reflected in the sample program for process Al, Figure 10. 
Here two eventcounts are declared and created, "ENEAl" and 
"ENDA3”. Eventcount ENDAl is used to synchronize with 
process A2. Specifically, ENDAl refers to the event 
corresponding to the completion of Al 's processing task. The 
occurrence of this event is signalled to process A2 through 
the Advance operation performed on eventcount ENDAl (located 
at the end of the "Do Forever" loop). The result of the 
Advance is to start the execution of process A2. After the 
call to Advance, process Al will loop hack to the call to 
Await with an awaited value of 1 this time and (if process 
A3 has not yet advanced SNDA3) will wait there. 

Process A2 is programmed as shown in Figure 19. 
Note that it first calls Await with the eventcount ENDAl and 
an awaited value of 1. This is in contrast to the awaited 
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PROGRAM MODULE Al; DO; 



/^' Leclare Sventcounts */ 

DECLARE ENDAK6) BITS DATA ('ENDA1%'); 

DECLARE ENDA3(6) BYTE DATA ('ENDA3%'); 

/* Declare a local word variatle ^'/ 

DECLARE A1$AGAIN WORD; 

/* Declare Synchronization Primitives */ 
CREATEiSVC; PROCEDURE ( EVENTCOUNT ) EXTERNAL; 

DECLARE EVENTCOUNT POINTER; 

end; 

AWAIT: PROCEDURE (EVENTCOUNT, VALUE) EXTERNAL; 
DECLARE EVENTCOUNT POINTER, 

VALUE word; 

end; 

ADVANCE: PROCEDURE(EVENTCOUNT) EXTERNAL; 
DECLARE EVENTCOUNT POINTER; 

END; 



/* Begin Mainline 

Al^AGAIN = 0 ; /^' To start execution immediately ••*/ 
CALL CREATE^SVC(0ENDA1) ; /* 

CALL CREATS$EVC (GENDA3); 

DO WHILE 1 ; /-' Do Forever *•'/ 

/* Checlr to see if processinf?: should begin */ 
CALL AWAIT (GENEA3,A1^AGAIN ) ; 



/* Processins completed so notify process A2 */ 
CALL ADVANCEOENDAl ) ; 

/* Increment the value to await '•'/ 

AliAGAIN = AliAGAIN + i; 

end; Of Do Forever */ 

end; /* Module */ 



EXAMPLE CODE FOR PROGRAM Al 
Figure 1£ 
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PROGRAM 'r^ODULE A2: DO? 



/* Declare Eventcounts */ 

DECIARE SNDA1(6) PYTE DATA ('ENDA1%'); 

DECLARE EN'DA2(6) BYTE DATA ('SNDA2%'); 

/^' Declare a local word variable */ 

DECIARE A2$AGAIN WORD; 

/* Declare Synchronization Primitives ’^/ 

CREATE$EVC: PROCEDURE (EVENTCOUNT ) EXTERNAL; 

DECLARE EVENTCOUNT POINTER; 

end; 

AWAIT: PROCEDURE(EVENTCOUNT, VALUE ) EXTERNAL; 

DECLARE EVENTCOUNT POINTER, 

VALUE word; 

end; 

ADVANCE: PROCEDURE (EVENTCOUNT ) EXTERNAL; 

DECLARE EVENTCOUNT POINTER; 

end; 

/* Be^in Mainline */ 

A2$AGAIN = i; /’!' To start execution after process A1 
CALL CREATE$EVC(0ENDA1); /- 
CALL CREATE$EVC(0ENDA2) ; 

DO WHILE i; Do Forever -/ 

/* Check to see if processing should bef'in '••/ 

CALL AWAIT (0ENDA1,A2$AGAIN) ; 



/« Processing completed so notify process A3 */ 
CALL ADVANCE(0ENDA2); 

/* Increment the value to await */ 

A2iAGAIN = A2$AGAIN + i; 

end; /* Of Do Forever 

end; /- Nodule -/ 



EXAMPLE CODE FOR PROGRAM A2 
Figure 19 
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PFOGRAM ^ODUIS A3; TO ; 



/* Declare Sventcounts */ 

DECLARF ENDA2(6) BITE DATA ('ENDA2%'); 

DECLARE ENDA3(6) BYTE DATA ('ENDA3%'); 

/* Declare a local word varia'ble */ 

DECLARE A3$AGAIN WORD; 

/•!■ Declare Synchronization Priinitives 
CREATE$EVC; PRCCEDUPS{ SVENTCODNT ) EXTERNAL? 

DECLARE EVENTCOUNT POINTER? 

END? 

A* AIT: PROCEDDRE( EVENTCOUNT, VALUE) EXTERNAL? 

DECLARE EVENTCOUNT POINTER, 

VALUE WORD? 

END? 

ADVANCE: PROCEDURE (EVENTCOUNT ) EXTERNAL? 

DECLARE EVENTCOUNT POINTER? 

END? 

/* Begin Mainline */ 

A3^AGAIN = 1? /* To start execution after process A2 -/ 
CALL CREATE^SVC (OENDA2)? /- 
CALI CREATEiSVC (GENDA3) ? . 

DO WHILE 1? Do Forever */ 

/•'' Checlc to see if processing should "begin */ 

C AL L AW A I T ( GS N DA 2 , A 3 i AG A I N ) ? 



/’!' Processing completed so notify process A1 
CALL ADVANCE(GENDA3) ? 

/* Increment the value to await */ 

AG^AGAIN = A3$AGAIN + 1? 

END? /- Of Do Forever -/ 

END? /* Module "V 



EXAMPLE CODE FOR PROGRAM A3 
Figure 20 



33 



value of 0 used by process A1 in its initial call to Await. 
Thus process A2 will wait at this point until signalled by 
process A1 (if process A2 begins executing before process 
Al). After A1 performs an Advance on eventcount ENLAl, A2 
will perform its processing and when complete will signal 
process A3 to begin via an Advance operation on the 
eventcount ENLA3. As with process Al, it will then loop back 
to the Await operation and will be suspended until Al once 
again signals it to continue. 

Figure 2C shows the program for process A3. 
Process A3 performs an initial Await as the others did and 
when its processing task has been completed, it signals 
process Al to begin the "loop" again via an Advance 
operation on eventcount FNDAS. 

These three processes are intended to 
demonstrate the mechanics of synchronizing with eventcounts. 
As can be seen, the operations used in all three of the 
processes are very similar. The real differences lie only in 
the Specific eventcounts that each process uses in the calls 
to Await and Advance. Note, however that each process 
performs the Await operation at a point that ensures the 
process will be synchronized with its companion processes 
even if the process begins "out of order". This is required 
to avoid confusion since there is no eiuarantee that the 
first of the three processes to begin executing will be the 
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one intended by the programmer to execute first 'viz., A1 in 
this example ) . 

h. Parallel Processing Example 

Suppose that instead of the simple sequential 
execution of processes, as in the above example, one wishes 
to execute processes in parallel. The eventcount mechanism 
provides the capability to synchronize parallel processes in 
(mechanically) the same way that sequential processing* is 
accomplished . 

Consider again the three processes A1 , A2 , and 
A3 from the previous example. This time the programmer notes 
that processes A2 and A3 both depend on input data (a set of 
filter coefficients, for example) from process A1 . However, 
he also notes that neither process A2 nor A3 alters the 
input data (they only read it). Thus processes A2 and A3 
become candidates for parallel execution since they both 
have a common event upon which to begin execution (the point 
where the input data becomes available) and they do not 
depend on each other. Note, however, they must reside in 
different microcomputers for their execution to actually 
occur in parallel. 

The desired flow of execution is shown in Figure 
21. Implementing the parallel execution of processes A2 and 
A3 is actually a simple task. Only process A3 need be 
changed. Processes A2 and A3 await the same value of a 
common eventcount rather than different ones. Thus the 
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Start Processing 




PLOW OF CONTROL IN PARALLEL PROCESSING 
Figure 2l 
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PROGRAM MODULE A3; DO: 



Declare eventcounts */ 

/- Eventcounts ENDAl, ENDA2 and ENDA3 */ 

/* Declare a local word variable */ 

DECLARE A3UGAIN WORD; 



DECLARE ENDA1(6) BYTE DATA ('ENDA1%')J 
DECLARE ENDA2(6) BYTE DATA ('ENDA2%')j 
DECLARE ENDA3(6) BYTE DATA ('ENDA3%')J 

/* Declare synchronization primitives 
/* Advance and Await */ 



/- Begin Mainline */ 

/* Create the eventcounts */ 

A3$ AGAIN = i; 

DO WEILE 1} /* Do forever / 

CALL AVAITCOENDAl ,A3$AGAIN) ; 

/* Perform processing */ 

• 

Processing of "both A2 and A3 complete */ 
CALL AWAIT(GENDA2,A3iAGAINn 
CALL ADVANCE(GENDA3) ; 

Increment the value to await '••/ 

A3$ AGAIN = A3$AGAIN + i; 



end; /- Of Do Forever -/ 



end; /* Of Module */ 



PARALLEL PROCESSING EXAMPLE PROCESS A3 
Figure 22 



92 



result cf a single Advance on tne eventcount will le to 
simultaneously signal processes A2 and A3. 

The operations performed hy process A3 is shown 
in Figure 22. Process A1 is still required to perform its 
processing first to provide input data for processes A2 and 
A3. Thus process Ai performs an initial Await operation on 
the eventcount SNBA3 with an awaited value of and since 
the eventcount is initialized to a value of 0 upon creation, 
Al will he allowed to continue. Processes A2 and A3 both 
perform their initial Await operations on the eventcount 
SNDAl using the same awaited value (they each wish to begin 
processing when the set of input data becomes available). 
However, process A3 will advance the value of IMPAS only 
after both A2 and A3 have completed. This allows Al to wait 
for the two events to occur (viz., the completion of 
processes A2 and A3) before it begins again. Thus with the 
single Advance operation performed by Al on 2NPA1 two 
processes begin execution. 

This example has shown how the programmer can 
easily make use of eventcounts to synchronize parallel 
processes with the same methodology used for sequential 
processes . 

c. Mutual Sxclusion Example 

Mutual exclusion is required in certain 
situations where one and only one process can be allowed to 
access a shared resource (some set of data) at a time. 
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MUTUAL EXCLUSION EXAMPLE 
Figure 23 
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PEOGEAM MODUIE PEINTER PROCESS: TO ; 



/* Declare eventcounts FULLB and EMPTY, used •'' / 
/* bv all of the processes */ 

DECIARE FULLE(6) BYTE DATA ('FULIB%'); 

DECLARE EMPTY(6) BYTE DATA ('EMPTY%'); 

/* Declare a local word variable */ 

DECLARE AGAIN WORD; 

/* Declare synchronization primitives */ 

Advance and Await */ 

/^' Begin Mainline */ 

/* Create the eventcounts 

DO WHILE i; /* Do forever */ 

CALL AWAIT (PFULLB, AG AIN ) ; 

/* Perform processing 

/* Processing: complete, notify others '''' / 
/* that buffer is available */ 

CALL ADVANCE(OEMPTY) ; 

Increment the value to await =*=/ 

AGAIN = AGAIN + i; 

end; /* Of Do Forever / 

end; /* Of Module 



PP INTER PROCESS FOR MUTUAL EXCLUSION FX AMPLE 

Figure 24 
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PROGT?AM MODULES A1 THROUGH kk: DO; 

/* Declare eventcounts FULLB and a sequencer */ 

/* used "by all of the processes. Sequencer */ 

/* hy all of the processes. Sequencer is 
DECLARE FUIIB(6) BYTE DATA ('EULLB%'); 

DECLARE EMFTT(6) BYTE DATA ('EMPTI%'); 

DECLARE TURNA(6) BYTE DATA ('TURNA%'); 

/* Declare some local variables among which is T */ 
DECLARE T WORD; 

/* Declare synchronization primitives 

/■■' Advance and Await as before plus Ticket */ 

TICKET: PROCEDURE (SEQUENCER) WORD EXTERNAL; 

DECLARE SEQUENCER POINTER; 

end; 



/* Begin Mainline */ 



• 

/* At this point process needs to print data 
so create the eventcounts as usual and create 
/* the sequencer '•'/ 

CALL CREATE$SEQ(GTURNA) ; 

/* Obtain a "turn” for the buffer '••/ 

T = TICKET (GTURN A) ; 

Wait for "turn" to come up * 

CALL AWAIT (GEMPTT,T); 

When awakened, process may use the ’•'/ 

/* buffer (its "turn" has come up) */ 

/* Finished with the buffer so notify */ 

/’•' Printer Process that there is output '•• / 

CALL ADVANCE(GFULLB) ; 

end; /"•* Of Module */ 



PROCESSES A1 - Ak FOR MUTUAL EXCLUSION FXAN’PLE 

Fifrure 25 
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Sequencers ere used in conjunction with eventcounts to solve 
these types of problems. 

To illustrate mutual exclusion, consider the 
flow of control in Figure 23. Here an unknown number of 
processes (A1 through Ak) require access to a single 
resource (used by A3). Printer Process is some i-rinter 
service and the single shared resource is its input buffer. 
Obviously only one of the processes requesting printer 
services can be allowed to write into the input buffer at a 
time and no process can write into the buffer while Printer 
Process is trying to transfer the information to the 
printer . 

The solution is show^n in Figures 24 and 25. 
Figure 24 shows the programming of Printer Process and 
Figure 25 shows how each of the processes requiring printer 
services are programmed. 

In Figure 16, Printer Process only requires the 
use of eventcounts (since it does not alter the data in the 
input buffer). It only needs to know when to begin 
transferring the data and to signal that the buffer is free 
upon completion of the transfer. Thus Printer Process only 
uses two eventcounts, FULL and FMPTT corresponding to the 
buffer's containing data from a process (FULI ) and its being 
emptied by Printer Process (EMPTY). Thus Printer Process 
performs an Await operation on FULL and waits for an input 
process to give it some data. When a process performs an 
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Advance on FULL, Printer Process will be awakened to output 
it. When Printer Process finishes outputting: the data, it 
will perform an ildvance on the eventcount FMFTT and loop 
hack to the AWAIT. 

The other processes, Figure 25, are to use the 
same eventcounts, performing Awaits on the eventcounts EMPTY 
(waiting for the buffer to become available) and lUII 
(signalling Printer Process that there is data to print 
out). Fowever, the awaited value is derived from a TICKET 
operation on the sequencer TURN. Note that each cf these 
processes will perform TICKET operations on the same 
sequencer (TURN) and so will all receive" unique awaited 
values ("turns’*, as in taking a number from a ticket machine 
at a department store, [13]) for the buffer. These TICKET 
operations will return a unique value for the sequencer 
every time it is called irrespective of which process calls 
TICKET (provided the same sequencer is used as the 
argument). Then the processes simply wait for their "turns" 
to come up. Since each process will wait for its "turn", 
there will only be one process writing into the buffer at a 
time. 

This example demonstrates the use of sequencers 
in mutual exclusion problems. As can be seen, the use of 
sequencers provides a very simple way to mediate access to 
shared resources, particularly useful when the number of 
processes involved is not known in advance or may change. 



93 



D. THE OPERimNG SYSTEM GATE 

Sornehow there must exist a liakase between the user 
processes and the operating system to use the functions 
outlined in the preceeding paragraphs. This is provided ly 
linking to each user process one operating system module 
known as a GATE. The GATE contains the PullTc declarations 
for the synchronization procedures which the user may 
access. The GATS, then, allows the user to call operating 
system procedures in exactly the same way that any EXTEPNAL 
procedure would he called. The advantage is that only the 
GATE (which is very small) must he linked and loaded with 
each user process, not the entire operating system. 
Additionally, during system generation [16], the Gate is 
located (PL/M terminology for the assignment of absolute 
addresses) in exactly the same place in memory for all of 
the processes. The result is that the Gate segments loaded 
in with each process will be overlayed. Thus all of the 
processes on a single microcomputer will share the same copy 
of the Gate code. This minimizes the amount of physical 
memory used by the Gate. 

Figure 26 tabulates the required format for all of the 
external procedure declarations that must be included in 
each user module making use of operating system functions. 
Note that only the functions actually used need to be 
declared . 
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Creating an Eventcount: 



CREATE$EVC: PR0CEDUEE(E7ENTC0UNT ) EXTERNAL; 

DECLARE EVENTCOUNT POINTER; 

end; 

Creating a Sequencer: 

CREATE^SEO: PROCEDURE(SEQU5]NCER ) EXTERNAL; 

DECLARE SEQUENCER POINTER; 

end; 

The Advance Operation: 

ADVANCE: PROCEDURS (EVENTCOUNT ) EXTERNAL; 
DECLARE EVENTCOUNT POINTER; 

end; 

The Await Operation: 

AWAIT: PROCEDURE( EVENTCOUNT .VALUE) EXTERNAL; 
DECLARE EVENTCOUNT POINTER, 

VALUE word; 

end; 

The Ticket Operation: 

TICKET: PROCEDURE( SEQUENCER ^ BITS EXTERNAL 
DECLARE SEOUENCER POINTER; 

END; 

The Read Operation: 

READ: PROCEDURE(EVENTCOUNT) BYTE EXTERNAi; 
DECLARE EVENTCOUNT POINTER; 

end; 



KERNEL CALL EXTERNAL PROCEDURE DECLARATIONS 

Figure 26 
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E. SHARED PROGRAM CODS 



Processes can 'be made to share code as lon^ as they are 
all loaded on the same microcomputer and the shared modules 
all have the 'REENTRANT' attribute. This places all variable 
stora<ee on the stack so that there is no confusion when two 
processes try to invoke the module at the same time. 

Because the system is bus-oriented (all of tne 
microcomputers share a single system tusK code sharing 
should not usually be forced for processes which reside in 
different microcomputers. This requires access to the system 
bus for instruction fetches making this technique less 
efficient. Therefore, global sharing of code is not not the 
expected convention during system generation, although it is 
not prevented outright [ 16 ]. In fact the programmer will not 
be in direct command as the system generation operator will 
make this decision. 

One rule of thumb that quite often applies to attempts 
at optimization is that the memory that is saved is paid for 
with a loss of speed. Quite often one can speed execution up 
drastically if he is not overly concerned about using 
memory. 

In summary, the sharing of code segments to save memory 
is a technique that is discouraged in this system if the 
processes which share them reside on different 
microcomputers. It will "work”, of course, but has a very 
detrimental effect on performance. 
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F. SEAHFD TATA 



Sharing of data between processes is tightly-coupled in 
that the data is not explicitly transmitted from one process 
to another. Father, data sharing is accomplished by using 
shared PI/M data segments. These shared data segments can 
reside in global memory where they are directly accessible 
to the processes concerned. 

FI/M allows one to develop programs modularly by 
providing data declarations with PUBLIC and EXT3RNAI 
attributes. When the modules are linked, all of the declared 
variables (such as byte, word and pointer quantities, 
arrays, structures, etc.) are collected into a single data 
segment for the program. Thus PI/M-S6 expects that each 
program will have its own local data segment. 

In modules where a variable is declared with the 
EXTERNAL attribute, it is understood that the variable may 
actually reside in a non-local data segment. The intention 
is that eventually, when all of these modules are linked 
together into one program the PUBLIC and EXTERNAL references 
will be resolved. 

Processes, though are not linked together. Tney are 
altogether independent PL/M programs. However, one can share 
data in much the same way as the modules in a single PL/M 
program by declaring all shared data in the processes with 
the EXTERNAL attribute. Thus each process will be aware of 
the existence of a separate data segment. The shared data 
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segment is then separately created as a FI/M tnodule 
containing only shared data declared with the PUFIIC 
attribute — no local data or code is ever included. This 
nodule is then compiled separately and linked to each of the 
processes sharing the data as if it were simply another 
program module. The only difference is that this module will 
only have a meaningful data segment. The code segment will 
he empty. 

It must he emphasized that such data segments are the 
only means of communication between processes. In 
particular, a reference to an absolute address (including 
constant or computed pointer values) is allowed. To do 
so will destroy the integrity of this operating system 
design . 

G. FRI?I13GED INSTRUCTIONS 

Fecause the operating system controls the physical 
resources of the system, certain instructions which are 
valid in either the high level language FI/M or the £0£5 
assembly language ASM-36 may not te used. The reason for 
this is that their use will interfere with the correct 
operation of the system. 

1. Interrupt Masking 

The operating system uses the interrupt structure of 
the system for its own purposes. Because of this, the user 
must never, repeat NEVER, mask interrupts using the assembly 
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lan^ua^e CLI/STI instructions or the PL/M-S6 EIS^ B1S/5N *.ELE 
instructions . 

The operating system uses interrupts system-wide 
during normal operation and requires that interrupts he 
unmasked at all times while user processes are executing. 

This is not to he confused with the use of interrupt 
handler routines which are required for certain software 
packages , notably the PL/M-86 real number library routines. 
These will not interfere with system operation. 

2. Input/Output Operations 

Direct access to Input/Output facilities is also 
the purview of the operating system. Thus the user is also 
prohibited from using the PL/fi and ASM-36 I/O instructions. 
Instead* a system service is provided to perform I/O 
functions for the user. 
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APPENDIX E - KEPNSL ISODULES 



This section contains the detail "pseudo-code" 
for the Icernel nodules. These have not heen 
fully tested and should only he considered an 
aid to understanding and not final code. 



^ Sit :1c 5^: j;: 5l: 5 ;: j;? :;r :|c i\i >;c ;;; 5 ;: / 

/* TEE INNER TRAFFIC CONTROLLER */ 

^ if if if if if if :;r if if if !fi,i if if if if if if if * * if if it if * ;;; si; * if if tf if if if 5 ;; it s;j tf if it if j? / 



/’!' VIRTUi>L PROCESSOR SCHEDULER V 

/s!c^;:!c5;:3}:J!c5!c«:;cs{cs!ci!c:;:s!cj(f!{ts!c;’cijcj;ty^:{e!!c5!es!:j!c5lcj!c:!es!esfcj:c^s:jy^::<«^y^j:c::c;’^3lcj!c::::{c:!s:{cs:c«Hc>:c«>;cs^:Ic5;c>:« / 

; External PL/M-66 procedures called hy this nodule 
EXTRN GETWORK: FAR, 

RUNTHISVP; FAR, 

RDTTHISVP: FAR, ' 

' LOCEVPM; FAR, 

UNLOCKVPM; FAR 

SCHEDULER SEGMENT 
PUBLIC YPSCHSDULER 
VPSCHEDULER PROC FAR 



ASSUME CStSCEEDULER 
ASSUME DSrNOTEING 
ASSUME SS:N0TEING 
ASSUME ES:NOTEING 



Entry point for a call to YpScheduler 
Establish activation record, save registers that 
YpScheduler will use. 

PUSH DS 
i=USH AX 
PUSH CX 
PUSH PP 
CALL LOCHVPM 
CALL RDTTHISVP 
MOV BP,SP 
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MOV CX,0H 



; ”0H" indicates normal return 

; Entry point for a preempt interrupt. Reached hy a jumn 
; from ITC_PREEmPT_KAN'DIER procedure. 

INT_ENTRY: PUSH CX 

” CALL GETUOPS ; Returns new "EBR" in the 

> AX register 

POP CX 

; Swap virtual processors. This is accomplished hy saving 
; the SP and BP registers in icnown locations at the base 
; of the stack along with the VpScheduler return type 

; flag. The process hound to the selected virtual 

; is accessible via the address space descriptor, 

; the SS register value. 

MOV SS:W0RE PTR C.SP 
MOV SSrWORI) PTR 2, BP 

MOV SS:W0RD PTR 4,CX J Return type flag 

MOV SS.AX > New address space desc. 

; Swap is complete at this point since the SS register 
t now holds the new stack segment value 

MOV SP,SS:W0RD FT?. 0 
MOV BP, SS: WORD PTR 2 
PUSH AX 
CALL RUNTHISVP 
MOV CX,SS:W0RD PTR 4 

; Check VpScheduler return type flag to determine the type 
; of return required for the process. 

CMP CX,77F ; Return type flat = Interrupt? 

JNE NOPM_RET ; If not, do a normal return 

JMP INT RET J If so, do an interrupt return 

NORM_REf: Call UNLOCKVPM 

POP BP 

POP CX 

POP AX 

POP DS 

RET 

VPSCHEDUIER ENDP 

itc_preemft_fandler proc par 

ASSUME CS .-SCHEDULER 
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ASSUME ES:NOTHING 
ASSUME SSrNOTHING 
ASSUME ES: NOTHING 

IMT_VEC: CLI 

PUSH ES 
PUSH DS 
PUSH AI 
PUSH CX 
PUSH DX 
PUSH EX 
PUSH SI 
PUSH DI 
CALL LOCKVPM 
CALL RDTTHISVP 
JMF INT_ENTRT 
INT RET: CALL UNIOCKVPM 

CALL CEECKPREEMPT 

POP DI 

POP SI 

POP BX 

POP LX 

POP CX 

POP AX 

FOP DS 

POP ES 

IRET 

ITC_PREEMFT_HANDLER ENDP 
SCHEDULER ENDS 



%*# %♦# %•• %*# %•# %l# / 

^4^ ^4^ ^4> #4% #1% #4% ^4% #4^ ^4* ^4% ^4* #4% ^4% *4* ^4^ #4^ ^4% ^4% ^4^ ^4% *4^ ^4% ^4^ ^4^ ^4% #4% ^4* ^4% #4* ^4^ ^4« ^4% ^4* ^4^ #4* #4^ <4% ^4^ ^4% ^4^ ^4* / 



/■' 



Virtual Processor Scheduler Internal Modules 



/ %^r %i# %*' «l# %*<» %*# ^4^ %4» %4# %4^ «4^ «4^ %4^ «4^ ««« «9# %*# %4^ ^9^ «9^ ^4^ ^4, ^9^ %*s W 

^4« ^4^ ^ 4 «^ ^4% ^4% ^4% ^4% r4% ^4^ ^4'* ^4^ ^4^ ^ 4 « #4^ ^4^ ^4* » 4 % ^4^ ^4^ ^4> *4*^ ^4^ *4* ^4« ^ 4 ^ ^ 4 ^ «4« ^4^ ^ 4 ^ ^9^ ^4* ^4^ ^ 4 ^ ^4^ ^ 4 ^ ^9* *^ 4 ^ ^4^ ^4^ ^1 

/* Externally Defined Variable Declarations 

DECLARE VPM(l) STRUCTURE 

(VP$STATE BYTE, 

VP$PRIORITI BYTE, 

EVCUW$ID BYTE, 

EVC^AVivALIIE WORD, 

SS$REG WORD, 



V 

5* j ;*j ;•? ^ 
'■'/ 



FE5PEND 



BYTE) external; 



DECLARE VPM$LOCK BYTE EXTERNAL; 



107 



DECLARE (GPU$NUMBER, VP $S TART, VPiEND, VPS i?ER$ CPU ^ 

3YTE external; 



DECLARE IDLE^DBR WORD EXTERNAL; 

DECLARE CPU$INT$VSCT0R(16) BYTE EXTERNAL; 



/’•' Literal constants 



/ 

'•V 



DECLARE FALSE LITERALLY '0 ' . 

READY LITERALLY 'l\ 
RUNNING LITERALLY '3', 
WAITING LITERALLY '7 ' , 
IDLE LITERALLY '15', 

TRUE literally '119'; 



/’•• External Procedure Declarations 

TC$PE$HANDLER : PROCEDURE EXTERNAL; 
END; 



/❖Jit: 

/- 

/«-. 

/- 

/- 

/* 

/* 

/- 

/- 



« «l# V** ^ ajLi %IU ^ %!,» «ju «l« %•« « 

^ 5jV ^1% #1% *4* »,• »4* *4» • 

GETWORK procedure 



Function call. Searches the Virtual Processor 
the highest priority runnahle virtual processor 
(state is either reaDy or idle with the Preempt 
Pending Flag set). Returns the DBR value (SS 
Re^?ister value) of the hound process in the Ax 
Register . 



Map 



p «*« »•* »•* •*« %•* •** ••rf «•* ••# » 

p V,* #1% «|% ^1% «4* ^4* ^1% #4« ^,P ^4% « 



« «*« «'« •*« 



»<# »•» / 
'I' -r* / 

:::/ 

-«/ 

-/ 

-/ 

"V 
=::/ 
.<U / 

/ 



GETWCRX: PROCEDURE WCRD REENTRANT PUBLIC,* 



DECLARE (PRI,I) BYTE; 

DECLARE SELECTED^DBR WORD; 

/* Begin search of the Virtual Processor Map usine* the */ 
/* priorities. Initially set to the lowest possible. •'■/ 

PRI = 255; 

DO /■••' Search Virtual Processor Map for the highest '-V 

/* priority ready virtual processor to run. */ 

I = VPiSTART TO VP^END,* 

IF /* The virtual processor can he selected, it is ■'•/ 
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/’•' is either the ready state, or the idle state 
with a virtual preempt pending. 

( (¥PM(I) .VPiPRIORITY < PRI) AND 
(?FM( I) .VP$STATE = READY OR 
(VPr^( I) .7P$STATE = IDLE AND 
VPM (I ) .PERPEND = TRUE))) THEN 

DO> /* Select the virtual processor. */ 
SELECTED$DBR = VPM(I ) .SS|rEO; 

PRI = VFM(I) .VPiPRIOEITY; 
end; /* Do. Select the virtual processor. */ 

end; /•'' DO loop search of the Virtual Processor Map. ^'/ 

/* Return the SS$HEG value of the selected virtual 
/* processor in the AX (Accumulator) Register. 

RETURN SELECTED^DBR; 

end; /* GETWORK Procedure. -/ 






0 ou 



RUNTHISVP Procedure 



/- 

/'•' 

Sets the selected virtual processor to running. 
/'•' Searches the Virtual Processor Map with the 

/- process's SEIECTED$DBR. 

^ OU 0X0 OU < 

•^1^ #1% #1^ ^1% ^1% ^1% ^1% ^1% #1^ #1^ #1^ rg> ^1% ^1% ^1% rj’* rj** ^4^ <1% ^4% <4% ^4^ ^4^ ^4-* ^ 



❖ 



/ 

/ 

/ 

/ 

/ 

/ 

/ 



RUNTHISVP: PROCEDURE(VPiDBR) REENTRANT PUBLIC; 
DECLARE VP$DBR ’*ORD, 

VP byte; 



VP = vp$snd; 

DC VHIIE /- Look for the VP with this SSiREG value. -/ 
(VPM(VF).SS$REG <> VP^DBR); 

VP = VP - 1 ; 



end; /^' Do While */ 
vpm(vp).vp$state = running; 

RETURN ; 

end; /- RUNTHISVP Procedure. *V 

/ UU «JU *X» %>« %** %l» «*« '«<« %*« / 

/ »|» «|% vp >p .>p ^1^ # 1 % «|« »!■» »!■» »!■» »,■» »,» »,» »,» *,■» »|-» / 



/- 



RDYTEISVP Procedure 



❖ / 
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/* Sets the currently running virtual processor's */ 
/* state to ready. 



RDYTEISVP: PROCEDURE REENTRANT PUILIC; 
VPM(ITC^RET$VP) .YP^STATE = READY; 

return; 

end; /* RDYTHIS7P Procedure */ 



/•'' LOCKVPM Procedure */ 



/* »/ 

/* locks the Virtual Processor Map. */ 






LOCKVPM: PROCEDURE REENTRANT PUBLIC; 



/* PL/M-66 built-in spin-lock procedure. *•’'/ 

DO WEILS L0CKSET(GVPM$L0CK,119); 

end; 



return; 

end; /* LOCKVPM Procedure. -/ 



/- UNLOCKVPM Procedure */ 

/* Unlocks the Virtual Processor Map. ^•‘Z 



/ s;; s;s Sj5 « 5|: 5^; ^ ;|{ s|; :,'t if. if if if :;5 if s’.t if if ;;s if if if if if -.{s s;: if if if if if ;;; y 

UNLOCKVPM: PROCEDURE REENTRANT PUBLIC ; 



vpmUock = z; 



return; 

end; /- UNLOCKVPM 



Procedure. */ 



:*t z\t s;; z\z i\s j;: z\i i\n\i 5 ;; z\i :|r :;sy,: i\z Jlij;: z\z i\x zlx , ?!: ^ 

/- EDWF$INT Procedure y 

/■'' Generates a hardware preempt interrupt. 

y jIt « -s if if if if if if if ifififififiiififififififif if if if « i |! if if i: if s;: if if if ii 5^ if * if Jlc if sj< * if * * if / 

EDWRilNT: PROCEDURE (CPU ) REENTRANT PUBLIC; 

DECLARE CPU BYTE, 



V 
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T 



FORTA LITRRAILY 'eCSH'; 

OUTPUT(FORTA) = CPU$INT$V3CT0R (CPU) J 
RETURN 

end; /- EDVF^INT Procedure. */ 

/* Inner Traffic Controller Interface Modules */ 



/* IDLE$FP Procedure */ 

/* Sets the state of the virtual processor now */ 
/* running to idle, hinds the ’’idle DBR", sets a */ 
/* high priority and calls Vp_Scheduler. '‘V 



IDLE$7P: PROCEDURE REENTRANT PUBLIC; 



DECLARE VP$T0$IDIE BYTE; 

VP?T0$IDLE = ITC$RET$7P; 
VPM(?P$TOiIDLE).VPiSTATE = IDLE; 
7PM(7P$T0$IDLE).VP$PRI0RITY = 10; 
7PM(VPiT0^IDLE) .SSiREG = IDLE^DER; 
CALL 7PSCEEDULER; 



return; 



end; IDLE^VP Procedure. -V 



^ %i^ ^ ^ %u ou V# ^ ^ %f# %•# «f# %•# y.^ ^ ^ m 

i #1% ^ #1% •»!% ^ ^ *^4' ^ ^4^ ^r* ^ -y* ^ 4' '■4' / 

/- ITCiLOADiVP Procedure */ 

/❖ «/ 

/* Performs e "Swap Virtual DER". Binds the virtual */ 

/* processor to the new process, updates VP^FRIORITY ’•'/ 

/* and SSiREG, and sets state to ready. */ 

/%4^ ^|U %4# %l# «4# ^1# ^4^ %4^ «4^ «4# %4« %4^ / 

yr #4% «-,% J|% ^ ^ ^1* ^4^ *4^ ^4^ ^4^ V ^4' *’4*^^ ^4^ ^4'* ^4* ^4* ^4* ^4' / 

ITC^LOAD$VP: PROCErURE(PRI$PARM,DER^FARM) REENTRANT PUELIC; 



DECLARE PR I $ FARM BYTE, 
DBR$PARM WORD, 

load$vp byte; 
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/« Identify running virtual processor. / 
LOAD^TF = ITC$EET$VP; 

/•'' Find the virtual processor. */ 
VPM(L0AI5$VP).VP$STATE = READY? 
VP^>(LOAD^VP) .VP^PPIORITY = PRIiPARM? 
?PM(IOAD$?P).SS$REG = DER$PARM? 

/* Schedule the virtual processor. */ 

CALL 7PSCESDULER? 



RETURN? 



END? /* ITC$LOAD$VP Procedure. */ 

5 ** it jJc sf* lii *** *** 5** *** •** *** •** 5** i*-* *** *** / 

<^<» ^ -f* »f» ^ *1^ n* •r* 'r* ^ <nr» ^ 1 ' *T* *T» ^ ^ **r» ^ ^ ^ ^ nr ^ n* ^ ^ nt* 'i' «*c 'r* 'T* ^ 'r nr 'r "r "r ^'* *r* n'* / 

/* ITC^RST$VP Procedure -/ 

/’'• '“'/ 

/* Function call which returns the identity of the */ 

/*^ virtual processor which is now running on the */ 

/* physical processor. */ 

/ %!# %V «JU %l# %l^ %1# JU OU sO / 

^1% >f« «4« #1% ^1% #1% ^|%^|« ^1% >!%#!% ^1% ^4% ^4% #1% >1% ^4« ^1% ^4% #1% ^4% ^1% ^4« y 



ITC$RET$7P: PROCEDURE BITE REENTRANT PUBLIC? 



/* Search through the set of virtual processors assigned */ 
/* to the phsyical urocessor. '^/ 
RUNNING$VpUI) = VP^START? 



DO WHILE /* Have not found the running virtual processor ^'/ 
(VPM(RUNNING|vP$ID) .?P$STATE <> RUNNING)? 



/* Search next entry. ^'/ 

RUNNING$?P^ID = RUNNING$VF$ID + 1? 

END? /* While loop search for running VP. RUNN INGiVP$ IE */ 
/* points to the running virtual processor. */ 



/* Return the identity of the virtual processor 
/* in the AX (Accumulator) Register */ 

RETURN RUNNING$VP$ID? 



END? /- ITC$RET$VP Procedure. -/ 



/* 

/❖ 



CHECKPREEMPT Procedure 



:.‘t3!c >•: 5 ;: 3 *; 3*,i 3*^3;« sj: s;s sjj s;< 5{s Jtc sj: 5|i ?r sj: / 



❖/ 

’V 
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/- Checks f 

/* is one, 

/* Handler. 

/ ^ ou ^ ou v« «ff «iu 

/ ^ ^ 



or a virtual preempt pending. If there 
calls the Traffic Controller Preempt 



u *(# wu 4 

> •,* «T(» 



❖ / 
'r »i» / 



CEECKPRE3MFT; PROCEDURE REENTRANT PUBLIC,* 

DECLARE RUNNING$VP BYTE,* 

/'•' Find the identity of the running virtual processor */ 
RUNNING^?? = ITC$RET$VP; 

DO VEILS Preempt Pending Flag of the virtual =•'/ 

/* processor is on. ^'/ 

VPM(RUNNING$VP) .?E$PEND = TRUE; 

/'•' Reset Preempt Pendiae: Flaf?. */ 

VPM(EUNNING$VP) .PE$?END = FALSE; 

/* and call Traffic Controller Preempt Handler. 

CALL tc$pe$eandleh; 

RUNNING-??? = ITC^RET^??; 

end; /* While loop handling of the virtual preempt. */ 

return; 

end; /* CHECKPREEf^PT Procedure. -/ 



/❖ 

/- 

/❖ 

/- 

/* 

/- 

/%iu 

/'•' 

/* 

/❖ 






• 






« %V 



ITCiSEND^PREENPT Procedure 



Issues virtual preempts (preempt interrupts to 
virtual processors) ty setting the appropriate 
Preempt Pending Flag in the Virtual Processor f^ap 
and then issuing a hardware interrupt if the 
processor is on a different physical processor. 



> #1% 



jjj J,c : 



%•♦ ♦ 



5|^ 5^C 5|! ^ 

.*/ 
-7 
’tv 
>v 
't'/ 
*/ 
o:v 



ITCiSEND$PREEMPT : PR0CEDURE(TGT^CPU,VP^ID ) REENTRANT PUBIIC; 

DECLARE TGT^CPU WORD, 

vpiiD word; 



/* SET THE PRE-EMPT PENDING FLAG -/ 

VPM(TGT^CPU - ?PS$FER^CPU + ?P$ ID ) .PE^,PEND = TRUE: 
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IF (TGT$CF'J <> CPU$NUMBER) TH3N 
CALL HI)WR$INT(TGT$CPU),* 



return; 

end; /- ITCiSEND$PREEMPT Procedure. ’V 



^ ^ :{s :*£ sj: 3{c :*c 5{s 5jc 3jc ^ 5|e 5^6 sjc ^ ?}c ^ 3*; 5^ / 



/- 

/>!c. 

/* 

/- 

/* 



ITC$A>fAIT Procedure 



-/ 

❖/ 

Eventcount synchronization mechanism for use hy the */ 

Inner Traffic Controller in the management of */ 

system resources. */ 

»*« %!• %*# V# %!• %ju %!• ^ ttJL# ^ ^ ou %v y 

^4^ ^4^ ^4^ «4^ ^4^ #1^ ^4^ ^4^ #|« ^4^ »4^ •!» #4% #4% #|^ ^4% 0^% ^4% #4^ 0^^ «1« #|^ 0^^ ^1% 0^% ^4% / 



ITCiAWAIT: PROCEDURE (EVC $ID , AVAITED^VAIUE ) REENTRANT PUEIIC; 
DECLARE EVC$IB BYTE, 

AWAITED?? ALUE WORD, 

RUNNING^VP BYTE, 

I byte; 

/* loch the Virtual Processor Map */ 

DO WHILE L0CKSET(0?PM$L0CK,119); 

end; 



do; 

/* Identify the running virtual processor 
RUNNING$VP = ITC^RET^VP; 

IF SYS$EYC^TABLE(E?C$ID) < AWA ITSD$VALUE THEN 

do; 

VPM(RUNNING$VP) .VP^STATS = WAITING,* 
VPM(RUNNING$VP) .EVC$AW^ID = EVC$ID; 
VPM(RUNNING$?P) .EVCiAWiVALUE = AWAITED$VALUE ; 

end; 



ELSE 

VPM(RUNNING$?P).VP$STATE = READY; 

end; 

/* Schedule the virtual processor. '•'/ 
CALL vpscheditler; 

/* Unlock the Virtual Processor Map. "V 
VPM^LOCK = e; 
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RE TUP N * 

end; /* ITCiAWAIT Procedure. "V 



/' 

/- 

/❖ 

/- 



ITC$ADVANCS Procedure 



Eventcount signalling inechanism. Used 1)7 the Inner 
Traffic Controller in mana^in^ resources. 



7 

•'•V 

—7 



y* 5*? ?f: :|c y,: sjt jjc :Js 3|j sjt s|: sj: j|: jJ: ^ 5|c 



* / 
• ^1% ^4^ ^4% >4^ ^4^ ^4^ ^4% ^1% >1^ ^4^ ^4^ ^4^ #4^ ^4^ / 



ITC$AD?ANCE: PROCEDUHE(SVC$ID) REENTRANT PUEIIC 
DECLARE EVC$ID lYTE, 

I BYTE; 



/'•' Lock the Virtual Processor Map */ 

DO WHILE L0CKSET(0VPM$LCCK,119) ; 

END; 

SYS$EVC$TABLE(EVC$ID) = SYS $EVC$TABLS{ EVC$ID) + i; 

DO I = 0 TO (NRiVPS - 1); 

IF VPM(l).EVC$AWiID = EVCilD THEN 

IF V?M(I ) .EVC$AWiVALUE <= SYS$EVC$TAILE(EVCiir ) THEN 
DO* 

VPM(I).VPiSTATE = ready; 

V?M(I ).EVC$AW^ID = 255 ; 

VPM( I ) .EVC^AV/^VALUE = 0; 

IF (I < VP^START) OR (I > VP$END) TEEN 
CAL L EDVR i I N T ( I /V PS ^ PER ^ C PU ) ; 

end; 

end; 

CALL vpscfeduler; 



/* Unlock the Virtual Processor Map */ 
VPMiLOCK = 0 ; 



RETURN; 

end; /"' ITC^ADVANCE Procedure. =-V 



*A* >1 

^ 



SJC ?4? 5 



% ^4^ »4’ 



/ 

^4% / 



TRAFFIC CONTROLLER 



/ teiU ^4 

y #1% #4% «4« «4% #4% ^4% >1^ ^1% ^4%>|% #4% #1% ^1% ^1* #1% #4% #1% ^1% ^1% 






^4% ^4^ #4% ^4% ^1% 



J7 

❖ / 



%V 

^4^ ^4^ ^1% ^4^ ^4^ ^1% ^4% ^4%^|% ^1% #4% ^4% ^4^ ^4% ^1% «4% #4% ^4% ^4^ ^4^ ^4% ^4^ ^4% #4% ^1% ^1% ^4% #1% ^4% ^4% ^4% «4^ ^4% 

/* External Global Data Declarations 

/ %!# ^1# 

^4%» 7|% ^4% ^4% #4% ^1% ^4% ^4% ^1% ^4% ^4% ^4% ^4% ^4** ^4^ #4-* ^1% ^4% ^4^ ^4% <4^ ^4% ^1% ^4% a»|% ^4% <^4% #4^ ^4-^ ^4% ^^% J^^ ^4^ ^4* 



/ 

/ 

/ 
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DECLARE AFT(l) STRUCTURE 

(STATE BYTE, 



AFFINITY 

VP$ID 

PRIORITY 

lOAD^TEREAD 

E?C$7ALUE$AW 

THREAD 

DER 



BYTE, 

BYTE, 

BYTE, 

BYTE, 

VORD , 

BYTE, 

WORD) external; 



DECLARE APT^LOCK BYTE EXTERNAL; 



DECLARE PROCESSES BYTE EXTERNAL; 

DECLARE L0AD$LIST(16) BYTE EXTERNAL; 

DECLARE EVC$TA3LE(1) STRUCTURE 
(E¥C$NAME(6) BYTE, 

E¥C$VALUE VORD, 

apt$ptr byte) external; 

DECLARE EVENTS BYTE EXTERNAL; 



DECLARE SEC^TABLEd) STRUCTURE 
(SEQ$NAME(6) BYTE, 

SEO$VALUE WORD) EXTERNAL; 

DECLARE SEQUENCERS BYTE EXTERNAL; 

DECLARE (C?U$NUf"BER,VP$START,VP$END,V?S$?ER 

BYTE external; 



DECLARE (NR$PEPS ,NR$VPS) BYTE EXTERNAL; 
DECLARE CPU$INTiVECT0R(16) BYTE EXTERNAL; 



DECLARE PRO^PARAM 
(FLAGS 
CS 
I? 

ES 

DS 

AX 

CX 

rx 

BX 

SI 

DI 



STRUCTURE 
WORD , 

WORD, 

WORD , 

WORD, 

WORD, 

WORD , 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 



$CFU) 
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ss 

PRIORITY 

AFFINITY 



WORD , 

PYTF, 

BYTE) external; 



/'•' 



Literal Constant Declarations 






DECLARE 



FALSE LITERALLY 
ready LITERALLY 
RUNNING LITERALLY 
BLOCKED LITERALLY 
TRUE LITERALLY 
MOT$FOUND LITERALLY 
NIL LITERALLY 



'O'. 

' 3 ', 

' 119 ', 

' 255 ', 

' 255 '; 



/• 



External Procedure Declarations 






ITC$RET$VP: PROCEDURE BYTE EXTERNAL; 

end; 



ITC$LOAL$?P: 



end; 



PROCEDUFE(PEI$PAR.'^,DBR$?ARM) EXTERNAL; 
DECLARE PRiipARM BYTE, 

DBRipARM WORD; 



IDLEiVP: PROCEDURE EXTERNAL; 

end; 



iTCiSEND^PREEMPT : PROCEDURS(TGTiCPU,VP^ID) EXTERNAL; 

DECLARE TGT$CPU WORD, 

VPilD WORD; 



end; 



/ ::: s;: sU ;|s :;r 5 |: 5;: :;c s;: ?;c s': 5;: j.: 5;: f 



/- THE PROCESS SCREEULER 

s;? >|s 5 |: ?!c ?;: ?[: :,•! ?[: if. if if if if if if if if if if if if if if iU i^i\;iift^if:^ ;|c if if if if if if if if if if if if / 
y if if i: if if 5;? if 5;: if if if if if if :;s if if 5;? if if if if if if if 5 ): s;: 5;; :;c s.’r if if if if s;r if if ^ 

/* TCiSCEEDULER Procedure */ 

/* Process scheduler. Searches for the highest */ 

/* priority runnahle process to load onto the -'V 

virtual processor. If no runnahle process is 
/* found, will idle the virtual processor. */ 



y 5;: if 5;: f,: if s): if if if if if if :;s i^i if 3;: 5;: if :;r if if 5 |: if if if if if if if if if if if if s!? if if ?!? Vt s'; / 

TC^SCEEDULER : PROCEDURE REENTRANT PUBLIC; 
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DSCLARS PROCESS BYTE, 

SSLECT$?EOCESS BYTE? 

PROCESS = LOflD$LIST(CPU$NUr^BER) ; 

SEIECT^PROCESS = FALSE? 

/* Search down Load^List for the highest priority '■'/ 

/'^ ready process runnahle on this physical processor. 

DO WHILE /* Have not found a runnahle process. */ 

(SELECT^PROCESS = FALSE)? 

IF /* Faven'^t reached the end of the Load^List / 

(PROCESS <> NIL) THEN 

DO? /* Check process. */ 

IF /=•'= Process is ready. *•'/ 

(APT(PROCSSS) .STATE = READY) TEEN 

Select the process to run. 

SELECTiPROCESS = TRoS? 

ELSE 

/* Check the next orocess. ■'•/ 

PROCESS = APT(PROCESS ) .LOAD$TERSAE? 

END? /* If then else. '*•'/ 

END? /* While loop search for next ready process. */ 

IF /•■' Have found a ready process to run. •'' / 

(SELECT^PROCESS = TRUE) THEN 

DO? /* Give away the virtual nrocessor. 

APT (PROCESS ) .STATS = RUNNING? 

APT(PROCESS ) .VP$ID = ITC$RET^VP? 

CALL ITC^LOAD^VP(APT(PROCESS ) .PR lOR ITY , APT (PROCESS ) .DBR ) ? 
END? Give away the virtual processor. 

ELSE 

/'•' No runnable process has been found so idle the ■■' / 

/’*' virtual processor. */ 

CALL IDLE$VP? 

RETURN? 
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SNP; /- TC^SCHEDULER Procedure.-/ 



/ «Li ^ ^ JLi «Li «L. «1« »U «*<• »l» «JLi «JU »)Li V' %*» .«•» V* »•* *** *f* ^•» «*.• *<» 3?* 2?I / 

»!■% ffi ..|» »|» «y« «f* «|% ..|^ «y« «|« «|« »|> rf,» #,• «|« ^1* «|> ^|> »|» ^j» »(• / 

/* PROCESS SCEEPULER INTERNAL MODULES -/ 

/ «^ «!>• «A« «t« «% «C •X* *A« «A«*jU «V h*" *A* «!.• «l« «l^ «l^ *!.> «)Li«># *A* %f* *A« WU vL. «C .JU «•« «l« .,(« «V *JU «*« %f* •J^ <J^ *f* «)L> *X^ / 

rf|% #1% »|* .>^ ^1* #1* *t* *f* *T(* *3* *3' 'C 'I* •*!* *t* *3' *3' *1' ^ 'I' 'I* 't* *3'' *•* *lF *3* '■|^ '♦* 't* *3' *t* / 

/ »•» «t* «t* V' V* *•«»•» ^3m *X* %X» 0« iX* V? *** *** »♦» »*« »V *•> %•• »♦» »*» *•» »•» »*» 0» «>« %•« %*» »>* »•» %•» »•» %♦» »•» »•» i 

<»i* ^)% »|» <(» ^4% ^|» »j» »(» »|» »(» »,» »i» »,» •(< »4» »i% #|» »|» »»» r,» »|» »(» r, » r,» »|» »(• / 

/- TC$LOCATE$EVC Procedure. -/ 

* / 



/-- 

/- 

/* 

/<C 

/- 

/❖ 

/- 



Function call. Returns the identity of the 
eventcount (the index of the eventcount in the 
Eventcount Tahle) in the AX (Accumulator) 
Register. Input argument is a pointer to the 
byte array in the user process holding the name 
of the eventcount. 



-/ 

-/ 

-/ 

«/ 

*/ 

-/ 



y jJ: sic :}: sj: ;Js :}£ s|c ^ 3{s sjc jjcsis 4= 3»«5is:;c:;s;js?;:5jc?fc5*t2ls5;«5;c:|;5|c Jlcsjcsjcsjcsjcsjcsjcsjc:*::!:;!?:;: Jlcr'.csJcsicJ'.—I^IsJiiJt; ^ 

TC$LOCATE$EVC ; PROCEDURE(E$NAME$PTR ) BITS REENTRANT PUBLIC; 

DECLARE E$NAME$PTR POINTER; 

DECLARE CHAR BASED SiNAME$PTR ( 5 ) BYTE; 

DECLARE I BYTE, 

EVC$ID BYTE, 

MATCH byte; 



I = 0; 

EVC$ID = 0; 

MATCH = false; 

/- Search down the eventcount table to locate the -/ 
/* desired eventcount by matching the names -/ 

DO WEILS /- haven't found the eventcount and 'V 
/* haven't reached end of table ^'' / 

(MATCH = FALSE) AND (EVC$ID < EVENTS); 

IF /- the two characters match ’!'/ 

(CEAR(I) = EVC$TABLE(EVC$ID).EVC$NAME(I)) THEN 

do; /- Check for end of strings -/ 

IF /- Reached the end of the strings */ 

CHAR (I ) = '%' THEN 

/* Have located the desired eventcount ^'/ 
MATCH = true; 
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ELSE 



/^' Look at the next character */ 
I = I + i; 

end; /* Check for end of strings */ 
ELSE 

do; /* Ready for check next entry 
I = 0 ; 

EVC$ID = EVC$ID + 1 ; 



end; /’’■* Ready for check next entry */ 

end; /* While loop search for desired eventcount '■' / 

IE /’•' Have found the eventcount 
(MATCH = TRUE) THEN 

/* Return its index in the SVC$TABLE */ 

RETURN EVC$ID; 

ELSE 

/'*' Return NOT^EOUND error code */ 

RETURN N 0T$ found; 

end; /■' TCiLOCATE^EVC Procedure. */ 



^ ^ ^ ^ sj 



u ^ «ju a.* Ui* a# a.* / 

^1% #1% ^1% #1% ^1% ^1^ #■!% #1% ^1% #1% #1% ^|« ^1% ^1% / 



/- 

/«. 

/* 

/- 

/« 

/- 

/* 



TC-^LOCATS^SEQ Procedure 



Function call. Returns the index in the 
sequencer table of the sequencer name ^?iven 
to it. Input arguament is a pointer to the 
string name of the sequencer in the application 
program. 



%v y^ y^^^ yu y^ y# ^ 

i ^1% ^ ^ #p ^ 1 % # 



-V 

.«/ 

-/ 

-/ 

❖/ 

❖/ 

■■/ 



TC^LOCATE^SEC : PROCEDURE( S $NAME^PTR ) BYTE REENTRANT PUBLIC; 

DECLARE S$NAME$PTR POINTER; 

DECLARE CHAR BASED SiNAMEiPTR (5) BYTE; 
DECLARE I BYTE, 

SEQ^ID BYTE, 

MATCH byte; 
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I = e; 

ssoiiD = 0; 

KATCE = faise; 

/* Search down the sequencer table to locate the */ 
/* desired sequencer by matching the names. ’’V 

DO WHILE /* Haven't found the sequencer and */ 

/* haven't exhausted the list. 

(MATCH = FALSE) AND (SE0$ID < SECUENCEHS ) ,* 

IF /* The two characters match. */ 

(CHAR(I) = SEQ$TABLE(SEC^ID) .SEC$NAME(I) ) THEN 

do; /* Check for end of strings. 

/ 

IF /* Reached the end of the strings. */ 

CHAR (I) = '%' THEN 

/* Have located the desired sequencer. 'V 
MATCH = true; 

ELSE 

/* look at the next character. 

1=1+1; 

end; /■'•• Check for end of strin,es. '-V 
ELSE 

do; /* Ready for check of next entry. */ 

I = e; 

SSCilD = SSO^ID + 1 ; 

end; /* Ready for check of next entry. 

end; /* While loop search for desired sequencer. ■■' / 

IF Have found the sequencer. */ 

(MATCH = TRUE) THEN 

/* Return its index in the SEO^TABLE. */ 

RETURN SEC? id; 

ELSE 
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/* Return NOTiFOUND error code. 
RETURN NOT^FOUND; 



end; /* TC$IOCATE$SEC Procedure. -/ 




*/ 

••V 





/*■' A’a'AIT Procedure 



/« 

/* Inter-process synchronization primitive. 

A' Suspends execution of the calling process until 
/* the event specified in the input argument 

A 'ETC$VALiPARM ' has occurred (the eventcount 

/■•' reaches this value). The result is that the 
A process will "give away" the virtual processor 

A to which it is bound. 




AWAIT: PROCEDURE (EVENTCOUNT, VALUE) REENTRANT PUBLIC; 
DECLARE EVENTCOUNT POINTER, 

TTATTT'!? VA.T3T 



/* Assert global lock on the Active Process Table. */ 

DO WHILE L0CESET(C«APT$LCCE,119); 

end; 

/* Get identity of the virtual processor running on 
/'•■ physical processor. 

CURRENT^VP = ITC$RET$VP; 

/* Search the Active Process Table (by the load list 
/* to find the process bound to the runnin,? virtual 
/'^ processor. 

PROCESS = LOADALIST(CPU^NUMBER) ; 

DO WHILE /* Haven't found the process bound to this vp. 
(APT(PROCSSS ) .VPilD <> CURRENTiVP); 

/* Look at the next entry in the LoadiList. 

PROCESS = APT (PROCESS ) .L0AD$TEREAD; 



' / 






VALUE 

EVC$ID 

CUPRENT^VP 

PROCESS 



WORD , 
BITE, 
BYTE, 

byte; 
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ENC> /* While loop search of Load$list. */ 

/* Get the EVC$TA£IE index for this eventcount. */ 
E?C^ID = TC$LOCATE$EVC(E¥ENTCOUNT) ; 

IE /* This process is to enter the hlocked state. */ 
E?C$TAELE(E7C$ID) .E?C$EA1.UE < VALUE TEEN' 

DOJ /* Set the required APT values. */ 

APT (PROCESS ) .STATE = ELOCKSD; 

APT(PROCESS ) .VP$ID = NIL,* 

AFT (PROCESS ) .EVCiVALUE$AW = VALUE; 

/* Add blocked nrocess to head of blocked list. 
APT (PROCESS ) .THREAD = SVC^TAELE (SVC ? ID ) . APT^FTR ; 

/* Reset table pointer to the current process. */ 
EVC^TA£LE(EVC$ID) .APT$PTR = CURREN’T^VP; 

end; /* Do. Place process in the blocked state. */ 



ELSE 



/* If the event has already occurred, process will */ 
/* enter the ready state — it will not be blocked. */ 
APT( PROCESS ). STATE = READY; 

APT(PROCESS ).VP$ID = NIL; 

CALL tc^sceeduler; 

Unlock global Active Process Table Lock. 

apt$lock = c; 



RETURN ; 

end; /* AWAIT Procedure. */ 









^ 

^1% ^1% ^ 



OU UU ^ 

^1% #1% ^1% 






ADVANCE Procedure 



/❖— 

/« 

/- 

/« 

/❖ 

y :{: :|c 3j: jjc 5|c ^ 5fc 5^ 



=V 

-*/ 

«/ 

"V 



Used to signal the occurrence of a specified 
event. Increments the current value of the 
eventcount. Also signals all processes which 
are in the blocked state waiting for this event. 






• *♦* 

^1% ^1% ^1% >1% 



t 5,*t 5j- ^ 
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ADVANCE: PROCEDURE (EVENTCOUNT ) REENTRANT FUEIIC,* 



DECLARE EVENTCOUNT POINTER, 

EVCilD BYTE, 

PROCESS BYTE, 

PREV BYTE, 

PEP BYTE, 

VP BYTE, 

HI$PRI BYTE, 

PE$TO^SEND BYTE, 

PE$SENT byte; 



DECLARE PEiPHP(16) BYTE, 

PE^vp(4) byte; 



/* Assert global lock on the Active Process Table. */ 
DO WEILE LOCKSET(0A?T$LOCK,119) ; 

end; 



/*!' Increment the value of the eventcount by one. */ 
EVC$TABLE(EVC$ID).EVC$VALUE = 

EVC$TABlE(E7CiID).EVCiVALUE + i; 

/* Search Blocked List associated with the eventcount */ 
A' and unblock those processes waiting for this */ 

/* event. Set PROCESS to the first member of the */ 

/* Blocked List. -/ 

PROCESS = EVCiTABLE(E7C^3lD) .APT^PTR; 

PREV = process; 



/- Initialize PE$PKP array. */ 
DO PEP = 0 TO NRiPHPS; 

PE$PHP(PHP) = false; 
end; 



DO WHILE /* Not end of Blocked List. •''/ 

PROCESS o nil; 

IF A The event has already occured. ‘‘V 
(EVC$TABLE(EVC$ID) .EVC^VALUE >= 

APT (PROCESS ) .EVC$VALUE$AW) THEN 

do; a Unblock process (set state to readyU zero "!=/ 
A Eventcount Value Awaited entry of APT and 

flag the physical processor for preemption. "V 
APT (PROCESS ) .STATE = READY; 

APT (PROCESS ).EVC$VALUE$AW = 0,* 

PE^PHP(APT (PROCESS) .AFFINITY) = TRUE; 
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/=!= Remove process from the Blocked List. 

IF /••' First member of the Blocked List. ^'/ 
(PRE? = NIL) THEN 



Reset pointer around the deleted member. 

evc$tableUvc$il) . AFT$PTH = 

APT (PROCESS) .thread; 



ELSE 



/* Set previous member's pointer around the '!=/ 
/* deleted process. 

APT (PREV) .THREAD = APT(pROCESS ) .THREAD; 

END; /* Do. Remove process from Blocked List. */ 

/* SEARCH NEXT ENTRY */ 

PREV = process; 

PROCESS = APT(PROCESS). thread; 

end; /* While loop search of Blocked List. */ 

DO Look for the PHP's with VP's to oreempt. ■^/ 

PEP = 0 TO PFPS; 

IF A'* PEP is flagged for a preempt. */ 

PE$PHP(PHP) = TRUE THEN 

do; /- Find VP's to preempt. -/ 

DO /* Flag all VP's for preemption. -/ 

VP = e TO vps^PERicpu; 

PE$vp(vp) = true; 

end; /* Initialize PE$VP array. -/ 

EIiPRI= 0; 

PS$TO$SEND = 0; 

PROCESS = LOAD$LIST(PHP) ; 

DO WEILE /* Search down Load List to find those */ 
/•^ processes which should be running. -•'/ 
/* Determine vnhich VPs not to preemut. */ 
(PROCESS 0 NIL) AND 
(HUFRI < VPS^PER^CFU) ; 
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IF /* Found a process which should te running* */ 
that actually is running. ’-V 

APT (PROCESS ) .STATE = RUNNING THEN 

DO; /* Increment number found and do not 

/* preempt its VP. / 

HI^PRI = EI$PRI + i; 

PEiV?(AFT(?ROCESS) .VP$ID) = FALSE,* 

end; 

ELSE 

IF /* Found a process which should le running ='V 
/* hut is in the ready state. / 

APT(PROCESS) .STATE = READ! THEN 

DO; /* Increment number found and indicate 

/* that a preempt will have to be sent */ 
to get it running. / 

EI^PRI = HI$PRI + i; 

PE^TO^SEND = PEiTO$SEND + i; 

end; 

end; /* While loop search of Load List. */ 

PE$SENT = 0 ; Used to 'seep track of the =1=/ 

/^' number of nreempts sent. 'V 
VP = e; /’S' Begin at first VP on the PEP. */ 

DO WEILS /*•' There are more oreempts to send. */ 

(?E$SSNT <= PE$T0$SEND) 

IF /’S' A preempt is to be sent to this VP. ’='/ 
PE$VP(VF) = TRUE TEEN 

do; /’S' Issue the preempt and tally it. ’S'/ 

CALL lTCiSEND$PRFEMPT(PEP,VP) ; 

PE$SENT = PRESENT + i; 

END; /’S' Issue preempt. ’S'/ 

/’!' Check the next VP. ="/ 

VP = VP + 1 ; 
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END? /* While loop send preempts. 
end; /* While loop determine VPs to preempt. */ 
end; /* Determine PEPs to preempt. */ 

end; 



/* P.eady the calling process. */ 

/'•• Get identity of running VP. / 

VP = ITC$PET$VP; 

/* Search Load List Thread to find VPilD match. -'V 
PROCESS = LOADiLlST(CPUiNUMBER) ; 

DO WHILE /* Have not found process bound to this VP. */ 
(APT(PROCESS ).VP$ID <> VP); 

/* Loo’/C at next entry in Load List. 

PROCESS = APT(PROCESS ) .L0AD$TEREAD; 

end; /* While loop search of Load List. */ 

/* Ready the calling process. =i'/ 

APT( PROCESS) .STATE = READY; 

APT(PROCESS).VP$ID = NIL; 

CALL tc^scfeduler; 



/* Unlock Active Process Table. 
APT$LOCK = 0 ; 

return; 

end; /"• advance procedure. */ 



y 5^ sicsjc sjs jjc :|s :|s 5|s sf: sj: s': sj: j{: s,*i 5,'c 5|c ^ 

/* ticket Procedure ''/ 

/in « / 

/* Function call. Returns a unique sequencer value. */ 

/ %•» y* %•# •*» «•« %»• «•« **• %’# ••• %'»%•• %*• ••• %»• %’• *•» %•» «*« %•« / 

#1% #1% # 1 % ^1% X 



TICKET; PROCEDURE(SFOUENCER) BYTE REENTRANT PUBLIC; 
DECLARE sequencer POINTER, 

SEQ$ID BYTE, 

VALUE WORD ; 



127 



/* Lock the Active Process Table. */ 

DO WHILE LOCKSET(0APT$LOCK,119); 

end; 

/* Identify the sequencer. */ 

SE0$ID = LOCATS$SEO(SEOUENCER) ; 

/* First obtain value to be returned to the caller '•'/ 

VALUE = seo$taele(3eq$id) .seo$value; 

Then increment the value of the sequencer =!'/ 
SEC$TAPLE(SEO$ID) .SEQ$VALUE = 

seo$table(seo$id).seq$value + i; 

/’•' Unlock the Active Process Table */ 

apt$locl' = e; 

/•^ Return the value to the caller. 

RETURN value; 

end; /* TICKET Procedure. -/ 



V ? V * ^0 ^$0 ^0 ^^0 ^%0 ^$0 ^0 y 

#1% ^1% ^1% #1% #l« #1* #1^ #1% #1% #1% #1% #1% #1^ #1^ 0^^ ^1% #1% «^|% ^|i» £ 

/* read Procedure */ 

/* Function call. Returns the current value of the */ 

/’•= eventcount specified in the call. */ 

i VU % M 0 ^0 %90 %$0 %l# %^0 «*« %^0 %*« ^*0 %<# ^0 %^0 ^0 i 

i ^|« <F|% ^1% #1% #1^ #1% #|« ^11%#^ 01^ 0^ 0^ #1% 0^ #|« ^1% «|« 0 )fr #1% #1% #1% #1% #1% 0^ #1% ^|« #|« #|« #1% #1* #|« #1^ tf|« ^1* #|%^|% «|* #1% ^1* / 



READ: PROCEDURE (EVENTCOUNT) BITS REENTRANT PUBLIC; 
DECLARE EVENTCOUNT POINTER, 

EVC$ID BYTE, 

VALUE WORD; 



/'•■• Lock the Active Process Table. */ 

DO WHILE L0CISET(0APT$L0CK,119) ; 

end; ■ 

/* Identify the eventcount. */ 

EVCilD = LOCATE$EVC(EVENTCOUNT); 

/* ’’Read" the current value of the eventcount. 
VALUE = EVC$TABLE(EVC$ID) .EVC$VALUE; 

/* Unlock the Active Process Table. */ 

aptUock = 0; 

/'•' Return the current value to the caller. */ 
RETURN value; 
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end; /* READ Procedure. •'' / 



/* CREATE^EVC Procedure 

/* 

/- 
/* 



❖ / 
«/ 
-*/ 
*/ 
-/ 

-/ 

❖s;-'/ 



Creates an eventcount 
in the eventcount table 
the initial value of the 



by making an entry for it 
”EVC$TABLS" and setting 
eventcoun t to C. 



^ :J:5^ :|c >;< 3|c 5|s 5jc 5j: 5*^ J^c :,’s ^ s}; ^ ^ sjs :{s 3|i :Js ^ 



CREATEiEVC: FROCEDURE(E?ENTCCUNT ) REENTRANT PUBLIC; 
DECLARE E?ENTCOUNT POINTER; 

DECLARE CHAR BASED NAME (6) BYTE; 
DECLARE I bite; 



/* Lock the Active Process Table */ 

DO WHILE LOCESET(OAPT$LOCK,119) ; 

end; 

IE /* The eventcount had not already been created */ 
LOCATE$EVC (EVENTCOUNT) = NOT^FOUND THEN 

do; 

I = 0 ; 

DO /* Copy the name into EVC$TABLE */ 

WHILE (CKAR(I) <> '%') AND (I < 5); 

/'•* Copy the character into the table. */ 
EVC$TABLE(EVENTS).EVC$NAMS(I) = CHAR(I); 

end; /- While loop. -/ 

/'^ Insert the delimiter in the table entry. */ 
S?CiTA3LE(EVENTS) .EVC$NAME(I ) = 



/* Increment EVENTS to indicate a new addition. 
EVENTS = EVENTS + i; 

end; /* Create the eventcount. */ 

/* Unlock the Active Process Table. ••'/ 

APT$LocK = e; 



return; 

end; /- CREATEiSVC Procedure. -V 



%V «V vl- vu %X# «JU %•# i 

^ ^ ^1% ^ ^ ^ ^ ^ ^ #1% #1% ^ ^ ^ ^ / 



/- 



CREATE^SEC Procedure 



V/ 
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/s:.' 

/* "Creates” a sequencer ty establishing an 

/* the sequencer table "SSO$TA.BLE" and sets 

/* initial value to 0. 

/ %t^ cV <JU V«« «iU ^<i* «iU «JU %lri» 

«e|% <^|% >1% #1% #1% ^1^ >1% >1^ I^p^ #1% ^1^ #1% 01^ 0-/^ 0^ 0^ 1^1^ rui^ #^% ^|» #)% ^1% 0^ 0f% 0^% 0^% ^1% 0ff^ #1% 



entry in 
the 



» «*« ^ «U ^ «U *A» ^ JU « 

% #|« 4^1^ #1% ^ 



*/ 

=v 

'•V 

-/ 

-/ 



CP.EATE^SEC; PP.0 CEDUHE(SECUEN CEP) REENTRANT PUBLIC; 
DECLARE SEQUENCER POINTER; 

DECLARE CHAP EASED NAME (6) BYTE,* 
DECLARE I byte; 

/'-' Lock the Active Process Table */ 

DO WHILE L0CESET(GAPT$L0CK,113) ; 
end; 

IE /* The sequencer had not already been created */ 
LOCATE^SEO(SEOUENCER) = NOTiEOUND THEN 



do; 

1 = 0 ; 

DO /* Copy the name into SEQ$TABLE ■•'/ 

WHILE (CHAR(I) <> '%') AND (I < 5),* 

/* Copy the character into the table. */ 
SECiT.«BLE(SEQUENCERS) .SEQiNAME( I) = CHAR(I); 

end; /* While loop. */ 

/* Insert the delimiter '%' in the table entry. */ 
SEQ$TAELE(SEQUENCERS) .SE0$NAME(I ) = '%'; 

V 

Increment SEQUENCERS to indicate a new addition. */ 
sequencers = SEQUENCERS + i; 

end; /^' Create the sequencer. •••/ 

/* Unlock the Active Process Table. */ 

APT$L0CK = 0; 



return; 

end; /* CREATE$SEQ Procedure. */ 



y '*• 
/« 
/❖- 
/- 
/* 
/- 



^0 ^0 ^0^^0 %p0 %^0 «U WU «JU ^0 

0ff% #1% #1^ 0^ r|% #|« ^1% 0^ r|% ^1% >1% rp 

CREATE$PR0CESS Procedure 



"creates" a process by initializ 
initializing an entry for it in 
Table . 



:5[i :J:5|c:^5;c:;c:fc5{:5j::|s^cs;« sji ^ ?;c sji ?;c sjs >;t ^ 

-/ 



ing its stack and ••'/ 
the Active Process ’‘'/ 



130 






CREATS^PROCESS: PROCEDURE (PPB$FTR ) REENTRANT PUPLICJ 

DECLARE PPE^PTH POINTER; 

DECLARE INIT^STACKiERAMS STRUCTURE 



(FL 


WORD, 


CS 


WORD, 


IP 


WORD, 


ES 


WORD, 


DS 


WORD , 


AX 


WORD , 


CX 


WORD, 


DX 


WORD , 


BX 


WORD, 


SI 


W ORD , 


DI 


WORD, 


RET 


WORD , 


BP 


WORD, 


SP 


WORD) ; 



DECLARE INTERRUPT LITERALLY '119'; 



/* Lock the Active Process Table. ’^V 
DO WHILE LOCESET(0APT$LOCK,119); 

end; 



/* Set up initialization stack frame. ’*'/ 
INIT$STACKiFRAME.EL = FRO^PARAM.FL; 
INITiSTACK^FRAME.CS = PROiPAnAM . CS ; 
INIT$STACKiFRAME. IP = PROiPARAM. IP ; 
INIT$STACE$FRA^^E.ES = PROiPARAl^ .ES ; 
INIT$STACK$FRAME.DS = PRO$?ARAM .DS ; 
INIT$STACK^FRAME.AX = PRO^PARAM . AX ; 
INIT$STACK$FRAME.CX = PRO^PARAM . CX ; 
INIT$STACK$FRAME.DX = PROiPARAM .DX; 
INIT$STACEiFRAME.EX = PROiPARAM . EX ; 
INlT$STACKiFRAf^E.SI = PRO$PARA^^ .S I ; 
INIT$STACE^FRAME.DI = PROiPARAN! .DI ; 
INITiSTACKiFRAME.RET = INTERRUPT; 
INlT^STACKiFRAME.EP = C; 

INIT$STACE$FRAHS.SP = 6; 

/* Move initialization stack frame into memory. */ 
MOVB( PINIT$STACK$FRAME , PPB .DBR ,2c ) ; 

/*■' Enter process in A.ctive Process Table. */ 
APT(PROCESSES ) .STATE = PPB. STATE; 

APT(PROCESSES ) .AFFINITY = PPB .AFFIN ITY; 
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APT(PROCESSES ) .VP$ir = NIL? 

APT(PPOCESSES ) .PRIORITY = PPB . PRIORITY ; 

APT ( PROCESS ES ) ,EVC$VALUE$A¥ = ? ,* 

APT(PROCESSES ) .THREAD = NIL; 

APT (PROCESS ES ) .DBR = PPB.DBR; 

/* Enter process in the Loaded List ty priority */ 

PRET = nil; 

NEXT = LOAD$LlST(CPU$NUHBER) ; 

DO WHILE PP3. PRIORITY > APT( NEXT ) .PRIORITY; 

PRE? = next; 

NEXT = apt(next).load$teread; 
end; 

IE NEXT = NIL TEEN 

APT (PRE?) .LOAD $TEREAD = ENTRY; 

ELSE 

IF NEXT = LOAD$LIST(CP'JiNUMBER) TEEN 

do; 

APT(ENTRY) .LOAD$THRSAD = 
LOAD$LIST(CPU^NUMBER); 
LOAD$LlST(CPU$NUr^BER) = ENTRY; 

ELSE 

do; 

APT(PREV) .LOAD $ THREAD = ENTRY; 

APT(ENTRT) .L0AD$TEREAD = NEXT; 

end; 



/* Unlock the Active Process Table. */ 
APTU'OCK = e; 

return; 

end; /* CPEATE^PRCCESS procedure. */ 



/ «t. I 

/- 

/- 

/* 

/❖ 

/* 

/- 

/- 



V# 

•|% *1^ ^4^ ^4^ #1% ^1% ^4% #1% ^1% ^1% •!> ^1% #1^ #1% #|« «|% ^1% •!« #1^ ^4^ #4^ #|« #1% «4^ r|« #|% ^4% »j% #4^ #4^ •!% «|% ^4% 



TC$PE$EANLLER Procedure 



%•# / 

/ 

=V 
— '*V 

=v 

«/ 

-/ 

»/ 

/ 



Handles 
Traffic 
preempt 
virtual 
Controller. 



preempt interrupts. Called by the 
Controller in response to a virtual 
interrupt. This module serves as the 
interrupt entry point into the Traffic 



Constitutes a loop. <===-===-= 

UU vV %(« %*« «*# ^ 

»g% «|« #,» >|« ^1* <»|» •(% ^1% »,» ^ 



TC$PE$HANDLER: PROCEDURE REENTRANT PUBLIC; 

/* Lock the Active Process Table. */ 

DO WHILE L0CESET(0APT$L0CK,119); 
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end; 



CALL tc$scfedulse; 

/* Unlock the Active Process Table. 
AFT^IOCK = e; 

rstupn; 

end; /* TC$PE$HANDLEP. Procedure. "V 
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